From: Julian Snitow <vangczung@...>
Date: 2003-05-27T19:26:29+09:00
Subject: Re: Constant Definitions and Hiding

On Tue, 27 May 2003 09:55:03 +0200, Robert Klemme wrote:

> 
> "Julian Snitow" <vangczung@yahoo.com> schrieb im Newsbeitrag
> news:pan.2003.05.27.06.19.59.938412@yahoo.com...
>> On Mon, 26 May 2003 21:58:48 +0200, Robert wrote:
>>

[snip!]

>> In a language that lets you do such beautiful, fluid things with
>> functions, the C++ mindset can only hold you back. ;-)
> 
> What C++ mindset?  I'm doing Java for a living... :-))

Java is the kettle to C++'s pot. ;-)

> 
>> If you must distrust the programmer so much, you can either make bar a
>> class method  ( def Foo.bar ), and def print_it; p Foo.bar; end,  or, if
>> going the constant route, refer to Foo::BAR explicitly.   If you don't
>> specify that you only want the BAR defined in class Foo, and not some
>> subclass's idea of BAR, then the example you posted shows the correct
>> behavior on the part of the ruby interpreter.
> 
> Of course the interpreter is right (he always is, isn't he? :-)),

Erm, by "interpreter" I meant the program that does the
parsing/"compilation", i.e. ruby. :)

> but I
> find this a bit surprising.  Maybe this is not too big a problem, since
> the maintainer / writer of the sub class is likely the same person
> introducing the constant; but then, often one adds something later and old
> code breaks.
> 
>> Remember the line, "A computer never does what you want it to do; only
> what you
>> tell it."?   No amount of warnings will change that.  :-)
> 
> :-)
> 
> Hm, maybe it's a question of expectations.  OTOH I found it surprising
> that defining a singleton method that had been defined as a singleton
> method issues a warning, too.  But I can see, that it's reasonable to warn
> about this.
> 

I submit that referring to an unqualified BAR usually indicates that the
programmer probably intended for the local BAR to be used, as opposed to
specifying Foo::BAR.  I can think of several examples in which I might
legitimately want to extend a subclass's behavior by setting a new BAR,
and since Ruby already offers a clear, concise way to specify which of the
two cases you want, I think it's better to err on the side of
extensibility.

(Of course, since I'm aesthetically biased against the use of CONSTANTS inside a
class definition anyway, my opinion in this matter is "for entertainment
purposes only"! ;-)

Cheers,
Julian