From: Julian Snitow <vangczung@...>
Date: 2003-05-28T19:15:41+09:00
Subject: Re: Constant Definitions and Hiding

On Wed, 28 May 2003 00:35:26 +0200, Robert wrote:

> 
> "Julian Snitow" <vangczung@yahoo.com> schrieb im Newsbeitrag
> news:pan.2003.05.27.17.14.53.497596@yahoo.com...
> 
> [snip]
> 
>> > ... 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".
>>
>> By "extensibility" I mean the ability to change as much of a (sub)class's
>> behavior at runtime without being warned; I favor the "trust the
>> programmer" approach of permitting the definition of FooSubClass::BAR, on
>> the theory that the implicit/explicit scoping rules are there for a
>> reason, and that defining  class Bar < Foo; BAR = "something else"; end,
>> doesn't wipe out the definition of Foo::BAR.  Any unintended side-effects,
>> then, are localized, and will be caught during the debugging of class Bar.
> 
> Yep, true.  Maybe one shouldn't be too paranoid about things that possibly
> can go wrong. (They do anyway, as Murphy told us. :-))
> 
>> You'll note that if you redefine Foo::BAR in two different places, you're
>> already warned, so your proposed warning can't be justified on the grounds
>> that Bar::BAR would interfere with the operation of class Foo.  (*whew!*
> ;-)
> 
> Thanks for clarifying!
> 
> If I get the essence of your argument right, then maybe we should advocate
> not being warned about a duplicate singleton method definition.  IMHO it can
> be reasonable to define a singleton method more than once (i.e. as
> representation of state changes).  The question seems to be, whether it is
> more likely that a duplicate singleton definition is an error or intended
> behavior.  Oh well...
> 

For individual objects, it should probably be allowed (though with Proc
objects, it's work-around-able).  When redefining FooClass.bar_method,
however, the side-effects are decidedly *not* localized, and could
conceivably lead to some really hard to find bugs -- Messrs Singleton and
State can rarely abide each other's company. ;-)

In other words, my_object.foomethod should always be hot-swappable, but
MyClass.barmethod should be more tamper-evident... :-)

Cheers,
Julian