|
Dev - Sort these by name
|
Encapsulation
Posted on March 05, 2011 at 18:21
I just don't get it.
People treat the programmer that is using their code like an ordinary user. They treat you like you have no idea whatsoever about any kinds of programming concepts, and like you need everything to be spoon-fed to you through a list of implementation functions. Code class point2d { private: double x, y; public: double get_x() { return x; } double get_y() { return y; } void get_x(double val) { x = val; } void get_y(double val) { y = val; } }; versus: Code struct point2d { double x, y; }; The first completely ruins my ability to do useful things, such as pt.x += 1. Instead, I have to do pt.set_x(pt.get_x() + 1). Granted, you can still add operators and such to this if you're using C++ (not in Java) or add functions like add_x and add_y, but you have to then ask why the hell that you thought of this in the first place. Even for things like strings, I don't really get it. I mean, yeah, it's kind of pointless to make an array class which stores a pointer and an integer for length and then just modify the pointer directly. But it's stupid to "hide" this from the user when the user clearly knows that it's there, and to provide get() and set() functions which essentially allow you to modify the variable directly. I do understand if you're trying to only allow getting a value, but if it's just another programmer using it, why hide it? It's not like making the variables in a point class magically enable users to edit the points that are being used by the program. It's not like users would be able to access your database info if it's made public unless you're allowing them to execute PHP - in which case, you've already allowed the user to bypass anything. I mean, in the programming concepts in my Java class, they use examples in things like bank accounts. They make a class called BankAccount and add withdraw(), deposit(), and a constructor. But the variable containing the money is private. The rationale? We don't want you editing the money the BankAccount directly!!! But uh, it's already being done directly. If withdraw() and deposit() were functions that inputted PIN numbers and such to validate things or had limits, I'd be fine with that. But they're not. You're directly modifying stuff, and I don't see why you have to hide a number from me but let me edit it indirectly. I mean, even if the implementation is confusing, there's no reason to hide it. Oftentimes, the implementation is essentially defined by member functions - for example, std::vector has size() and capacity(). This already tells me that somewhere, there is a stored size and a stored capacity. And, it stores a dynamically-sized array, which tells me that it contains a pointer to said array. I've already identified the vector implementation. While the functions that are implemented may be changed, the data itself never changes. Why is it kept hidden? If I go messing into it and break the vector because of modified data, then that's my fault. But I don't see why you have to hide it from me. I'm too lazy to write a conclusion, so, there you go.
Hi.
Posted on March 03, 2011 at 17:15
Some of you might know me. And by some, probably a decent few.
I used to visit 64D in what... 2009? Before that, 2008. And even before that, but I really, really, really don't want to talk about before that. When v3 came out, it completely screwed my password, and I have to thank sirXemic for fixing it. It's really funny how you're working on a e-shop before working password recovery. Anyways, lately, I've been working a bit on various sites, as well as coding random things in C++ which make sense and have no purpose other than the fact that they may contribute slightly (if at all) to a game that I will make. And the game's a secret, so, you won't see much from me until it's closer to completion. X is a bitch, and so is STL. Due to the nature of how variadic templates work, things are stored backwards in memory. tuple<char, char, char>('\0', 'a', 'b') is stored as the string "ba" in memory, because tuple<char, char, char> : tuple<char, char> : tuple<char>, and tuple<char, char, char>* has to be compatible with tuple<char, char>* and tuple<char>*. This isn't very GL-friendly. That reminds me - my graphics card supports GL 4 (even though I bought before GL 4 came out), and nVidia is still stuck on GL 2. Intel is still stuck on GL 1.4. FML. But nonetheless, I'll continue dicking around with custom structs which mimic STL while avoiding making a game, despite wanting to make it. Either way, welcome back to me, I guess. I might post blogs more often. I would have cleared the list of "fans" on the left, but that seems impossible at the moment. Whatever. |

