Perhaps using constants inside a class is what ought to be warned.
class Foo
def bar
“bar”
end
def print_it
p bar
end
end
class Bar < Foo
def bar
“foo”
end
end
In a language that lets you do such beautiful, fluid things with
functions, the C++ mindset can only hold you back.
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.
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.
Cheers,
Julian
···
On Mon, 26 May 2003 21:58:48 +0200, Robert wrote:
Hi,
we had a discussion on #irc the minute before and I’m thinking that there
ought to be a warning in this situation:
class Foo
BAR = “bar”
def print_it
p BAR
end
end
class Bar < Foo
def print_it
p BAR
end
end
Foo.new.print_it
Bar.new.print_it
class Bar < Foo
next line should IMHO issue a warning
because of the hidden constant Foo::BAR
BAR = “foo”
end
Foo.new.print_it
Bar.new.print_it
Output:
“bar”
“bar”
“bar”
“foo”
This code does not warn (at least with 1.6.8) either with or without -w.
we had a discussion on #irc the minute before and I’m thinking that
there
ought to be a warning in this situation:
class Foo
BAR = “bar”
def print_it
p BAR
end
end
class Bar < Foo
def print_it
p BAR
end
end
Foo.new.print_it
Bar.new.print_it
class Bar < Foo
next line should IMHO issue a warning
because of the hidden constant Foo::BAR
BAR = “foo”
end
Foo.new.print_it
Bar.new.print_it
Output:
“bar”
“bar”
“bar”
“foo”
This code does not warn (at least with 1.6.8) either with or
without -w.
What do others think?
robert
Perhaps using constants inside a class is what ought to be warned.
class Foo
def bar
“bar”
end
def print_it
p bar
end
end
class Bar < Foo
def bar
“foo”
end
end
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… :-))
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? :-)), 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.
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
···
On Tue, 27 May 2003 09:55:03 +0200, Robert Klemme wrote:
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
···
On Tue, 27 May 2003 09:55:03 +0200, Robert Klemme wrote:
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”.
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.
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!
(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.
Thanks!
Cheers,
Julian
···
On Tue, 27 May 2003 13:32:13 +0200, Robert Klemme wrote:
On Tue, 27 May 2003 09:55:03 +0200, Robert Klemme wrote:
… 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…
… 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…
