Page 1 of 1

Change private to protected

Posted: Fri Sep 10, 2004 5:38 pm
by Ed Welch
I would make the following suggestion for the next release of wxWidgets. Change all private memeber variables and functions to protected, except where there is a proven case that private is really needed.
In most cases there is no advantage to make a member of a class private rather than protected and in a shared library like wxWidgets, you will have many cases where people need to override the underlying behaviour. Many of these cases aren't immediately obvious to the person that writes the origional class, so I say if in doubt, make it protected.

Re: Change private to protected

Posted: Fri Sep 10, 2004 5:51 pm
by Ryan Norton
Ed Welch wrote:I would make the following suggestion for the next release of wxWidgets. Change all private memeber variables and functions to protected, except where there is a proven case that private is really needed.
In most cases there is no advantage to make a member of a class private rather than protected and in a shared library like wxWidgets, you will have many cases where people need to override the underlying behaviour. Many of these cases aren't immediately obvious to the person that writes the origional class, so I say if in doubt, make it protected.
WX-devs are fairly maticulous about what they make private and protected.

Basically, if it's private, it's private for a reason :wink:

Posted: Fri Sep 10, 2004 5:59 pm
by Jorg
I think when all is protected and when deriving you are able to access the variables, you might break something because you do not fully understand why what variables are set and at what given time. So by making them all protected they will probably get 'bug reports' and cannot guarantee the workings of the classes.

If you really need the internals of a class, then I would suggest that, but making all of the classes protected, is a bit too much I think.

- Jorgen

Posted: Fri Sep 10, 2004 7:09 pm
by Ed Welch
I didn't say to make all private members protected, I just said there should be a good reason for making it private. The default case should be protected. This does not cause any problems. If a programmer tries to override something that he shouldn't, then it's *his* problem. He knows that he is mucking around in the internals and that it might not work out, but why prevent him from doing it?
I see many bugs logged where they had to change private members to protected and that it just a waste of time for everybody.
Jorg wrote:I think when all is protected and when deriving you are able to access the variables, you might break something because you do not fully understand why what variables are set and at what given time. So by making them all protected they will probably get 'bug reports' and cannot guarantee the workings of the classes.

If you really need the internals of a class, then I would suggest that, but making all of the classes protected, is a bit too much I think.

- Jorgen

Posted: Sat Sep 11, 2004 6:09 am
by Mampfred
If people derive from a class and use the protected member variables of the base class I would like to think that they know what they are doing.

+1 from me on changing member variable from private to protected. Not necessarily all over the place, but being less restrictive if it is needed would be nice.

See patch http://sourceforge.net/tracker/?func=de ... tid=309863 for example. It did neither get ignored completely nor did it get applied. Just left there without a definitive statement :(

Then again, it's a trivial patch to my local tree with every new wx version ... if that's what it takes to use wx I'll happily do that :)

Posted: Sat Sep 11, 2004 8:01 am
by eco
I wanted to derive a class from wxCalendarCtrl so I could change the date to any date, not just dates in the currently shown month but the data I needed to access was private. I was told on the mailing list that the control wasn't something that was intended to be derived from. Personally, all original intentions should be thrown out if something poses a significant problem like that did. Luckily there was a fantastic patch by Antti Merenluoto that not only fixed the problem I had but improved the wxCalendarCtrl GUI immensely. Unfortunately, the patch is yet to be applied (although, there has been talk...kind of). I really hope they put it in the next release because the control really is quite nice and will improve the ugly calendar control quite a bit and I'd hate to see Antii's great work pass by without notice. Anyway, I'm digressing. My point was, I could have spent 10 minutes deriving a new control from wxCalendarCtrl to do what I needed if some of the members changed from private to protected and if it weren't from Antii's patch, I would have probably just patched my copy with access specifier changes.

Posted: Sat Sep 11, 2004 8:17 am
by Jorg
I agree on that. I commented earlier that I thought Ed meant that everything that is private should be protected. I think maybe when the wxWidgets 3.0 comes out they have to consider every class present and see what members are really meant or inheritance and should be protected.

This is ofcourse much to ask and will only kick off if the majority of the people will request it, or a wxWidgets main developer does this.

- Jorgen

Posted: Sat Sep 11, 2004 3:42 pm
by geon
If a programmer tries to override something that he shouldn't, then it's *his* problem.
WRONG!

This is be basic concept of encapsulation. Anything that can cause a problem if handeled improperly should be private. That guarantees, that no external code can break a working, bug-free class.

Protected should be used whenever a member or method is useful, or can affect the behaviour, but is not crucial to the implementation of the base class.

However, I concur with you, that protected members/methods should be used in favor of private ones wherever it is 100% safe. (Safe: cannot force the base calss to crach or create unpredictable bahaviour.)