I am learning Ruby. It is my understanding that when we "override" a
method we *replace* the method in the super class with the new method.
In playing around, I discovered the mechanism illustrated in the code
below for *re-shaping* the result of the code in a super-class method.
I'm wondering if this technique is in common usage; and, if so, does it
have a name? (I know that it's not, "overriding". What is it?)
class Ace_high
def suit()
%w(2 3 4 5 6 7 8 9 10 J Q K A)
end
end
class Duce_high < Ace_high
def suit()
super().reverse
end
end
In playing around, I discovered the mechanism illustrated in the code
below for *re-shaping* the result of the code in a super-class method.
I'm wondering if this technique is in common usage; and, if so, does it
have a name? (I know that it's not, "overriding". What is it?)
This technique is *very* common. It's one of the basic features of
object orientation.
I read the wikipedia link. As a reader who knows nearly nothing, it
would seem to me that the methodology that I described would not qualify
as "overriding" according to the definition contained in the wikipedia
post because the wikipedia post (like other posts I have read) says that
in order to qualify as "overriding" the method in the child class has to
*replace* the method in the super class. In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used. None-the-less, if that is the
conventional wisdom, I'm happy to go along with it. I just need to
adjust my understanding of what "overriding" means.
Thanks again for the input and for helping me understand what
"overriding" means.
From the point of view of the caller you have 'replaced' the method with your custom (sub class) version. The fact that you are calling super is an implementation detail that the caller is blissfully unaware of.
I read the wikipedia link. As a reader who knows nearly nothing, it
would seem to me that the methodology that I described would not qualify
as "overriding" according to the definition contained in the wikipedia
post because the wikipedia post (like other posts I have read) says that
in order to qualify as "overriding" the method in the child class has to
*replace* the method in the super class. In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used.
I read the wikipedia link. As a reader who knows nearly nothing, it
would seem to me that the methodology that I described would not qualify
as "overriding" according to the definition contained in the wikipedia
post because the wikipedia post (like other posts I have read) says that
in order to qualify as "overriding" the method in the child class has to
*replace* the method in the super class. In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used. None-the-less, if that is the
conventional wisdom, I'm happy to go along with it. I just need to
adjust my understanding of what "overriding" means.
Thanks again for the input and for helping me understand what
"overriding" means.
In Ruby, the *overriding* actually is *shadow* the superclass's method
(hope that I used right word). You can't direct call the superclass's method
but it still around, it don't be removed.
When you call super, it'll go up in the class's
inheritance tree step-by-step
and find method with same name.
(sorry for my bad English)
Best regards,
···
On Fri, May 25, 2012 at 8:10 AM, Doug Jolley <lists@ruby-forum.com> wrote:
--
Duong Quang Ha (Hà Quang Dương in Vietnamese)
blog.haqduong.com
In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used.
It doesn't matter if the overriding method is actually completely new or
if it only "refines" the original one (i. e. still calls super).
In fact, the term overriding is purely technical. It only means that you
define a method which is already present in another class of the
inheritance chain. The actual content is not relevant. It may even
consist of only calling super (though this wouldn't make sense, of
course).
This is always the case in OOP, in fact that's the very definition of
method overriding. You could argue that in a compiled language the
functions are projected downward from the class into the instantiated
object, and therefore an intermediate subclass effectively blocks the
superclass's function projection, replacing it with its own function
definition; however that doesn't necessarily "destroy" or overwrite
the superclass's function (see: Java `super` keyword.)
To complete the jargon: "overriding" means defining a behaviour in a
subclass that supersedes the behaviour that would have been provided
by the superclass; "shadowing" means defining a datum in an inner
scope that does not write its value over that of a datum of the same
name in an outer scope; and "redefining" means replacing a value of
behaviour with another, irretrievably.
···
On 25 May 2012 12:31, Duong Quang Ha <quangduongha@gmail.com> wrote:
Hi,
On Fri, May 25, 2012 at 8:10 AM, Doug Jolley <lists@ruby-forum.com> wrote:
I read the wikipedia link. As a reader who knows nearly nothing, it
would seem to me that the methodology that I described would not qualify
as "overriding" according to the definition contained in the wikipedia
post because the wikipedia post (like other posts I have read) says that
in order to qualify as "overriding" the method in the child class has to
*replace* the method in the super class. In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used. None-the-less, if that is the
conventional wisdom, I'm happy to go along with it. I just need to
adjust my understanding of what "overriding" means.
Thanks again for the input and for helping me understand what
"overriding" means.
In Ruby, the *overriding* actually is *shadow* the superclass's method
(hope that I used right word). You can't direct call the superclass's method
but it still around, it don't be removed.
When you call super, it'll go up in the class's
inheritance tree step-by-step
and find method with same name.
(sorry for my bad English)
By the way: In Ruby you can leave out the parentheses for method calls
(unless there's ambiguity). So instead of
puts(clubs.suit().inspect())
you can simply write
I've been meaning to respond to this. Yes, I am aware of that fact.
Some claim that it makes the code more readable. I actually think that
it does the opposite and makes the code less readable. The reason that
I think that is that when I am reading Ruby code and I encounter an
identifier by itself, I don't really know whether that identifier is a
variable or a method. If I see an identifier followed immediately by
'()'; then, I know for sure that that identifier is a method.
Consequently, I try to remember to use explicit parenthesis. I doubt
that I do a very good job; but, that's my thinking.
You know what, I just realised I was reading Duong's message in
entirely the wrong context. Sorry if I threw any confusion in to the
mix.
In terms of analogy he's exactly right, and hopefully Doug will be
able to accept it as the truth it represents.
An alternative reading of the Wikipedia article in question could be:
"The implementation in the subclass overrides (replaces) the
implementation [provided by] the superclass [but only in an instance
of the subclass]. . . ." That's not to say that it overwrites any
part of the superclass. That's getting sort of meta.
···
On 25 May 2012 12:44, Matthew Kerwin <matthew@kerwin.net.au> wrote:
On 25 May 2012 12:31, Duong Quang Ha <quangduongha@gmail.com> wrote:
Hi,
On Fri, May 25, 2012 at 8:10 AM, Doug Jolley <lists@ruby-forum.com> wrote:
I read the wikipedia link. As a reader who knows nearly nothing, it
would seem to me that the methodology that I described would not qualify
as "overriding" according to the definition contained in the wikipedia
post because the wikipedia post (like other posts I have read) says that
in order to qualify as "overriding" the method in the child class has to
*replace* the method in the super class. In my example, I don't see the
method in the child class *replacing* the method in the super class
because the method in the child class actually uses the method in the
super class. I don't see how one can say that a method has been
*replaced* if it is being used. None-the-less, if that is the
conventional wisdom, I'm happy to go along with it. I just need to
adjust my understanding of what "overriding" means.
Thanks again for the input and for helping me understand what
"overriding" means.
In Ruby, the *overriding* actually is *shadow* the superclass's method
(hope that I used right word). You can't direct call the superclass's method
but it still around, it don't be removed.
When you call super, it'll go up in the class's
inheritance tree step-by-step
and find method with same name.
(sorry for my bad English)
This is always the case in OOP, in fact that's the very definition of
method overriding. You could argue that in a compiled language the
functions are projected downward from the class into the instantiated
object, and therefore an intermediate subclass effectively blocks the
superclass's function projection, replacing it with its own function
definition; however that doesn't necessarily "destroy" or overwrite
the superclass's function (see: Java `super` keyword.)
To complete the jargon: "overriding" means defining a behaviour in a
subclass that supersedes the behaviour that would have been provided
by the superclass; "shadowing" means defining a datum in an inner
scope that does not write its value over that of a datum of the same
name in an outer scope; and "redefining" means replacing a value of
behaviour with another, irretrievably.
You need to do whatever feels best for you. I'd just add if you do
not know whether something is a method or a local variable then your
methods might be too long or you use too many variables.
Btw, in this particular case there is an even better way to rewrite the code:
p clubs.suit
or, if you prefer parens
p clubs.suit()
p(clubs.suit())
If you need to inspect more complex structures results are better when doing
On Wed, May 30, 2012 at 5:50 PM, Doug Jolley <lists@ruby-forum.com> wrote:
By the way: In Ruby you can leave out the parentheses for method calls
(unless there's ambiguity). So instead of
puts(clubs.suit().inspect())
you can simply write
puts clubs.suit.inspect
I've been meaning to respond to this. Yes, I am aware of that fact.
Some claim that it makes the code more readable. I actually think that
it does the opposite and makes the code less readable. The reason that
I think that is that when I am reading Ruby code and I encounter an
identifier by itself, I don't really know whether that identifier is a
variable or a method. If I see an identifier followed immediately by
'()'; then, I know for sure that that identifier is a method.
Consequently, I try to remember to use explicit parenthesis. I doubt
that I do a very good job; but, that's my thinking.
