Re: [PEPr] Comment on RFC::ProtectedMembers

Hi Alan,

One of the key reasons for prefixed properties/methods is the visual expression of "Do not mess with this variable/method, I may remove/rename it in the future." - hence as child classes are expected to rely on that variable always being there, they should not have that marker..

My understanding was that this was at the very center of the issue, and was the reason for those early comments by people like Bertrand & Alexey that 'protected' has a lot more to do with 'public' than it does with 'private'. Certainly the above observeration is true. Protected represents a committment to child classes and as far as thos subclasses are concerned protected variables are just as constrained as public vars for how they change between releases. I would say that an author can use judgement on that last issue, though. Some classes are not designed to be extended by user classes even while they are extended by classes within the library. In these cases, I'm sure that a change to a protected var should not be viewed as a BC break. Hans