From: Robert Klemme <bob.news@...>
Date: 2003-05-27T20:46:49+09:00
Subject: Re: Constant Definitions and Hiding


"Julian Snitow" <vangczung@yahoo.com> schrieb im Newsbeitrag
news:pan.2003.05.27.10.23.28.960550@yahoo.com...
> 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. :)

That's what I thought.  Obviously you suspected, it was not what I
thought... :-)

> > 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.

.... leading you to which conclusion?  Sorry, I don't get what you indend
to say be "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"! ;-)

You might be pleased to hear that I found your comments entertaining and
interesting. :-)

Cu

    robert