Artem Kachitchkine writes: > > Thus, I don't think it makes sense to worry much about promotion or > > the disruption it would cause. It _does_ make sense, though, to make > > sure that users can be aware that they're touching bits that might rot > > over time. Naming (as in the link_* scheme) could be part of that. > > That makes perfect sense in a perfect world. But the mistakes you > mentioned can and will be made again. We provide an easier way of > creating/getting/setting properties, easier means accessible, accessible > means more people with less architectural insight are going to > contribute. You and Peter aren't going to look over each of their > shoulders, unfortunately :) If the only mechanism of enforcing your > design is human discipline, it can't be trusted.
Variable definition is hardly the sole or even primary domain of lousy design decisions. Yes, I agree it's entirely possible that people will in fact do stupid things with "private" variables. History has shown that's true. The only thing I can ask here is that all the available technical documentation for the private variable interfaces explains _clearly_ why creating a private variable, though it looks "easy," is in fact a Very Bad Thing, and suggesting strongly that well-defined public ones are better. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
