Pages: [1]   Go Down
Author Topic: use of 'protected' in lieu of 'private' for libraries and built-ins  (Read 914 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 1
Posts: 30
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

On more than one occasion I've needed to modify contributed and other open source libraries so that it will 'simply work' for my project, or work BETTER than the original for my project, and so on.  After all, in many cases you get what you pay for with free and open source libraries.  You get free code, and you get the source, at no actual cost except the labor you need to supply to make it work for what you are doing.

but the single BIGGEST problem I run into is the use of 'private' rather than 'protected' in the class definition.  It is something that I wish had NEVER been invented for the C++ language.  It basically means I have to edit the original header files to change 'private' to 'protected', or else re-name everything into my own copy of the original built-in class [and potentially have unnecessarily duplicated code in my HEX file].

So, WHAT compelling reasons exists to use 'private' instead of 'protected'?  I mean, really?

Why not just make a mass-edit of ALL of the code and convert 'private' to 'protected' so that it becomes EASY to write a derived class that does something specific and low level?  This is about as 'open' as you can get, after all.  No 'closed' class members, in other words.

As an example, I would like to do things with 'HardwareSerial' that take advantage of what's already been written (thanks), but instead of doing it "that way" for a particular function (let's say 'write()') I might have some updated high-speed buffer thingy that uses the head/tail pointers directly, making it possible to write out data FASTER than before at high baud rates.  I would need direct access to head/tail pointers to do this.  But they're 'private'.  If they were 'protected', they would still be unavailable to regular user code, but AVAILABLE to a derived class.  That's the point.  I _SHOULD_ be able to derive a class and directly access these members.

Granted, you can't always support that kind of thing in perpetuity, BUT AT LEAST YOU SHOULD MAKE IT POSSIBLE for people who want to do this, with an "at your own risk, this may change in the future" caveat.  I could, I suppose, write a "MyHardwareSerial" library by copy-pasting the HardwareSerial code and re-naming a few things, but that's probably not the best solution.

In any case, can you at least CONSIDER changing all of the "private" stuff to "protected"?  Please?

And this goes TRIPLE for contributed libraries.  Again, I wish 'private' had never been invented for C++, when 'protected' does what you want AND lets derived classes access the 'would be private' members.  After all, if you REALLY want to stop people from accessing those members, you should use abstraction.  'private' is completely unnecessary, and it gets in the way.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 5
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You make a case for your point of view when writing code for public release, as can be made for standard naming conventions and other practices. Some third party library's are written for personal use and then eventually 'cleaned up a bit' and made available as gifts to the Arduino community.  I think that comparability with the IDE is the only actual restriction  that should be placed on possible official contributions, not any particular code writing convention.

If you are writing code that builds upon another library speak to the library author. Most times they will be happy to help.

Mr. E
Logged

Pages: [1]   Go Up
Jump to: