Why the excessive use of Private classes?!
-
Look, I'm not trying to be condescending, but you are in fact, accepting everything without your own thought. Do you really think threadId in QThread is going to change much from 4.3.2 to 4.6.2, how about scroll position. There are so many very basic items that need not worry about changing, that they need not squirrel away in opaque types, thus the use of excessive in the title. Its like taking an OOP concept to an extreme. Technically speaking, making quint32 a class is good OOP design, but is it necessary, does it make life difficult for devs, should it be done? Putting literally (not figuratively) everything in private opaque types is the equivilant in OOP excessive. Thats all I'm going to say on the opaque types.
As for permissions, you know that 90% of programs out there are pretty basic gui apps, doing pretty basic things. Allowing 10% of them access to those things private isn't going to cause mass panic as you describe. 10% of the applications may be tied to a particular library version, and its the responsibility of those devs to upgrade it. However, its not like concurrent library versions can't exist on the same machine. To say its going to cause nothing to work anymore, a form of mass panic in the software world, is more of a hyperbole than anything I have said, only you seem absolutly serious about it.
Another example, this is like how there are 2 schools of though in the IT world, let the users manage themselves, and punish the lusers and don't give them any privileges lest they break something. Time and time again, the admins who allow the users who know what they are doing to do it, they have less work for themselves, sometimes have trouble users, but, thats how its going to be. The admin who lets no one do anything constantly finds himself barraged with calls to allow a program to be installed, or a folder to be created, and thus, sure nothing breaks, but he has more work for himself. Why then are we going to innundate trolltech with change requests for I need a getter, for value x. Why not just allow most common, stable items, and block only those things still in flux? You know, make it private only if there is a good reason for it?
I asked a few other devs I work with, and some I have still kept in contact with since college. We all work professionally, and have for some time, and all agree, protected is the way to go...its those who have never had to live with the consequences of that decision who still rally for it...Thats why I'm not surprised to see a library vendor still rallying around it, and of source when they hit a snag, they just change their own source, thus, never live with the conseqences of their decisions.
Let those of us with our 10% of applications do what we need to, and maintain our versions. If it turns out the functionality is as cool as we think it is, then we'll see about filing a change request and getting it into the main library interface. Making us have to rebuild the library for not a single change to the library source though, to access these private opaque types is just plain insane. At the very very least, I should be able to include the _p.h files, derive classes, and have things work without the incompatible qt library message coming up. I honestly really shouldn't have to go grab the source, find the _p.h file I need, find all the other _p.h files it includes, and that they include, only to come up with that obnoxious error message. I wasted 2 days on making a 64 bit scroll area, it should have taken 2 hours, and making it take 2 hours would not have harmed the software repositories, or the software contained therein, at all.
I really feel I have proven repeatedly now this is the case. I have been writing code since I was 8 years old, never liked the idea of private, and never used it except where it really was necessary. Since then I have worked as a professional dev, and had collegues thank me for my wider vision. Funny how it didn't break anything then, and will continue not to break things. It comes with an inherent risk, and I make that clear, but I don't need to babysit other devs, and I most certainly don't need you, or Trolltech to babysit me. I'm a big boy now, I know when I access a protected member, things might change on me, and I deal with it.
-
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?
