Why the excessive use of Private classes?!
-
With all due respect to your age and everything (although you were a bit late starter), but if you can say that "Allowing 10% of them access to those things private isnβt going to cause mass panic as you describe" then you have no idea how C++ libraries work.
I suggest diving a bit more into inner workings of C and C++ before making statements like these.
As for "Look, Iβm not trying to be condescending, but you are in fact, accepting everything without your own thought", I can only laugh and say that even if it were true, people I've been privileged to work with (and to learn from) in the last decade of my life are not held in high regards only by their colegues...
-
I do know how C++ libraries work. I also know how C libraries work. I also know the differences between windows and linux libraries, and the challenges of porting between the 2. I've worked pretty extensivly with all permutations of the above. I have worked with some of the most underrecognized (because of the field I happen to be in) brightest people you could imagine. We all fed off one another, and made some really disruptive stuff, in a short amount of time. I've worked with brilliant outside vendors for products, some who maintained their own libraries, some we maintained their libraries for them. Dont think for a second I don't have a lot of experience with what I'm talking about. Either you aren't getting what parts it is I am saying need change, you don't have the same understanding, or you're just accepting what someone else told you. I'm not really sure which it is. Reguardless, I have maintained binary compatibility in other more flexible means, I have never once had a problem with making things protetected that didnt need to be protected from a derived class. I can think of some...very popular, commercial...systems...that do just this, and feel no need to deny access. Goes right back to the sysadmin example...
That said, because of the overprotection, and simplicity of the QThread class, I now have a fully functional replacement, with more functionality than QThread, including read access to the thread ID (not handle/pthread_t object, the 32 bit id in windows, and linux. Dont much care for OSX for the stuff I write). Funny how overprotection leads to uselessness, and eventual replacement with something not overprotected. It shouldn't be this way, and many highly successful commercial ventures understand this principal very well.
-
If you're referring to my (to me anyways) hilarious hyperbole similes, then I'm glad you got the humor :) I try to make things funny all the time, and laugh at everything, including myself. If you think I'm an idiot, well, too bad, if you think Ivan's an idiot, again too bad. If you think the whole argument is funny, well, I suppose I can laugh at it too, but I am serious in that overprotection is as bad as underprotection :)
-
Let's just poke about in this discussion some more. Have a look at Meyer's "Uniform Access Principle":http://en.wikipedia.org/wiki/Uniform_access_principle . It states that
All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.
This is in my view a heavy endorsement of privately held data, while accessors are protected or public. This means you can dump everything into a pimpled class's private parts, while still having access to all information. More so, it gives you every freedom of changing the way the function works without having to force a recompilation of your entire program. Instead you only have to compile 1 source file and link the entire thing again.
Aside from that, having member variables directly accessible from the outside increases coupling of your classes. Your class is responsible for the state it is in, not the outside world.
-
Ok, first off, let me tackle what was said there, and what you said. Uniform notation, which does not betray...where do you get private from that? Thats saying to design a proper interface, and stick to it. What that is saying is hide how the data is generated, not hide the data. Read it again. The data can be private, protected, or public, and still have how the data is generated hidden. All it is saying is to have a function to access each element of the data that is accessible. I generally don't agree 100% with that, but I see the value in a lot of cases. However, if you are going to go that route, you really need to provide a FULL interface, not a partial one, which is my complaint with Qt. (Actually, I can't even really call it an interface since there would be, well, an interface, and an implementation, not a need to include a private data header...thus the reason I didn't immedatly recognize it as such).
Yeah, I can get access to the data I need for 90% of what I want to do. Accessors like text() and setText(). Fine, I guess its obvious I might want to do something with the text of widgets....but I don't know, I thought it would be obvious that I might want to have OS provided unique thread ids accessible for reading, but as it turns out, according to Trolltech, I'd be wrong. Clearly threads are supposed to be in their own little world doing their own little task. Only, I'm not. A properly designed interface would give me access to all the data members through accessors, because it would have been necessary for the implementation of the interface.
Basically the problem is like I said in a previous post they aren't forced to live with the consequences of their decisions, only I'll rephrase it slightly, by not going with a full interface seperation, they aren't being forced to live with the consequences of their decisions. When you seperate out the interface, you find you need accessors for everything, and you don't clutter things up with private headers with comments about how this will change, we mean it. Instead, they have to use, protected accessors for everything, because you have to derive from the interface to implement it. Thus, you live with the consequences of your interface design, and make sure you get it pretty well rounded before it ever hits release.
If you have ever worked with a library done in with full interface/implementation seperation, you know, theres nothing thats difficult to extend, oh, and it doesn't break binary compatibility. IMO, this hybrid approach is the lazy way out, and renders some classes, or rather pseudo-interfaces useless.
-
I totally agree with @Corry . Fortunately I only use Qt for hobby projects for myself or very small groups of people, because I always bump in these Private classes, and it always makes me so sad I stop using Qt for a long time. Sometimes I feel it's even worse than Java...
-
-
@6thC said in Why the excessive use of Private classes?!:
π Achievement Unlocked: 8 year necro π
This is quite possibly the oldest necro I've ever seen.
I can accept it in this case, since it's still an issue that people are concerned about :)
@vendelin, I agree that private implementations do make Qt harder for newcomers to modify, but I believe the benefits far outweigh the downsides. Most importantly, it allows Qt engineers to add features to existing classes without creating DLL Hell (in all platforms, not just Windows).
Can you elaborate on why private classes make you sad and how they affect your projects?
