From: mrilu Date: 2000-04-01T02:53:57+02:00 Subject: [ruby-talk:02320] Re: Question about attribute writers On Sat, 1 Apr 2000, Clemens Hintze wrote: > Dave Thomas writes: > > Clemens Hintze writes: > > > > > At least I would expect it! It is like answered in your FAQ! How does > > > Ruby determine what a variable is? It is really stright-forward, IMHO. > > > > > > Look if there was an assignment before > > > yes => compile a variable access > > > no => compile a method call. > > > > True - I asked the wrong question. Rather than asking "is this the > > expected behavior", I guess I meant "is this the behavior that someone > > would expect?" It seems to violate the principle of least surprise. > > Hmm difficult thingy here, I think. I would never assume that > > age = 12; > > could invoke a method, because I *know* that this syntax normally > means assignment to a local variable. It would be very strange to me Agreed. > > Perhaps a warning would a good idea in these circumstances: > > > > warning: local variable eclipses instance method > > Erhm ... IMHO this warning is wrong! Because there is *no*syntax* that > allow 'age = 12' meaning a method call to 'age='. So if this is No. Warning is really good, I think! It should just not be issued for age = 12. Only for next case as you then "correct yourself" ;) > I would propose the opposite, if we really want to issue an > warning. The warning should be issued for the case > > age / 12 > But I admit, that this solution would probably issue too much warnings > because the 'age / 12' syntax is often used! And your suspects (is it suspicious'? That has ambiguity too, help :) are probably right. But, what I would like to see is that I could ask interpreter to give his opinion, which is of course always right, to check if my assumptions are always in line with reality. So optional if -w should give some warnings, this could be activated at -w=3. > Perhaps it would be better to not change anything, and describe this > case very carefully in the books and docs. Every language has its > gotchas. We cannot eliminate all of them. This is one of Ruby. I fully agree.