From: Matthew Kerwin <matthew@...>
Date: 2012-05-25T11:52:26+09:00
Subject: Re: Don't override it - Use it

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:
>>>
>>> > And it *is* actually called overriding:
>>> > http://en.wikipedia.org/wiki/Method_overriding
>>>
>>> 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.
>
> --
>   Matthew Kerwin, B.Sc (CompSci) (Hons)
>   http://matthew.kerwin.net.au/
>   ABN: 59-013-727-651
>
>   "You'll never find a programming language that frees
>   you from the burden of clarifying your ideas." - xkcd
>



-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/
  ABN: 59-013-727-651

  "You'll never find a programming language that frees
  you from the burden of clarifying your ideas." - xkcd