From: Robert Date: 2003-05-28T07:51:56+09:00 Subject: Re: Constant Definitions and Hiding "Julian Snitow" 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... Cheers robert