Re: Re: Getting rid of "underscore for private method names" codingstandard

Hello Greg, > > 2. Having an underscore preceding private methods and > > class variables makes it impossible to open up the API without > > breaking existing code. > This assertion is untrue because by definition private > methods/variables are only used internally and are not a part of the > API, thus they can be changed/renamed at will using a search/replace > with no consequences. If one wants to expose a previously private > variable or method, as far as external users are concerned, this is > no different than adding a new variable or method. I think I made myself not clear enough: By "breaking code" I do not mean to break a public API. I mean making a method public as easy as possible. The easiest way is to replace "private" with "protected" or "public", and it's done. Currently, with a _ in front, you'd have to remove that and *change your code* (in this class) because it's broken now. That's what I meant with "breaking existing code". > However, I think a *far* better suggestion would be to forbid the use > of the private keyword unless the intention is to prevent any possible > modification because of race conditions or other critical coordination > issues. Instead, we require all variable to be protected or public > unless there is extreme justification. In my experience working with > other people's code, the "private" keyword simply makes it impossible > to implement code reuse without resorting to vast swaths of cut/paste. That would mean that everything is public API, thus "breaking API" will happen in most releases when internals change, and keeping BC is nearly impossible *except* the class layout was finalized before releasing the first beta. This is really hard, since internal changes like method reorganization or splitting of internal methods are almost impossible to do then without breaking the API, because everything is public API. How do you justify that? Or do we need a new definition of BC? > This will have the side effect of doing the exact naming suggestion > you've made, since the current CS forbids _naming with protected > variables/methods. Thank you for the interesting idea, that's something what I hoped to gain with the mail to pear-dev@ :) -- Regards/Mit freundlichen Grüßen Christian Weiske -= Geeking around in the name of science since 1982 =-

Attachment: [application/pgp-signature] signature.asc