From: Kent Dahl Date: 2002-09-13T16:02:34+09:00 Subject: Re: private variables Yukihiro Matsumoto wrote: > In message "Re: private variables" > on 02/09/12, Christian Szegedy writes: > |I thought, being private for a variable means that it can > |only be acessed by the methods of its class to avoid > |name collisions with instance variables in derived classes. > > Yes. Hence it should not be exported as an attribute method, which > can be seen from everywhere. Am I missing something? There is a (narrow) use here, where one might like to have a private instance variable and share it out with attr_* methods; avoiding namespace pollution in baseclasses that are to be subclassed alot. That is, one wants to use private instance variable to protect one self vertically in the inheritance tree. (I could see myself using both attr_writer and attr_reader on private instance variables, while attr_accessor is less likely.) Along the horizontal, I think that Ruby provides enough protection. Now, I don't see losing attr_* for private instance variables a big loss. But at the same time, I do not see it as a requirement that they are prohibited. If I was being terribly pragmatic about it, I'd implement private instance variables any way I could, and not really care about attr_*. If they still work with private instance variables, keep them. If they don't work, ignore them. Only time I would pour energy and time on them with regards to private instance variables, is if PoLS might be violated. For example, if the syntax would allow you to write an attr_* that appears to expose the variable, but it is actually some other variable that gets accessed. My 0.02 NOK -- (\[ Kent Dahl ]/)_ _~_ __[ http://www.stud.ntnu.no/~kentda/ ]___/~ ))\_student_/(( \__d L b__/ NTNU - graduate engineering - 5. year ) ( \__\_�|�_/__/ ) _)Industrial economics and technological management( \____/_�_\____/ (____engineering.discipline_=_Computer::Technology___)