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 <[e-mail]> wrote:
> On 25 May 2012 12:31, Duong Quang Ha <[e-mail]> wrote:
>> Hi,
>>
>>
>> On Fri, May 25, 2012 at 8:10 AM, Doug Jolley <[e-mail]> wrot=
e:
>>>
>>> > And it *is* actually called overriding:
>>> > http://en.wikipedia.org/wiki/Method_overriding
>>>
>>> I read the wikipedia link. =A0As a reader who knows nearly nothing, it
>>> would seem to me that the methodology that I described would not qualif=
y
>>> as "overriding" according to the definition contained in the wikipedia
>>> post because the wikipedia post (like other posts I have read) says tha=
t
>>> in order to qualify as "overriding" the method in the child class has t=
o
>>> *replace* the method in the super class. =A0In 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. =A0I don't see how one can say that a method has been
>>> *replaced* if it is being used. =A0None-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 me=
thod
>> but it still around, it don't be removed.
>>
>> When you call super, it'll go up in the class's
>> inheritance=A0tree=A0step-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. =A0You 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.
>
> --
> =A0 Matthew Kerwin, B.Sc (CompSci) (Hons)
> =A0 http://matthew.kerwin.net.au/
> =A0 ABN: 59-013-727-651
>
> =A0 "You'll never find a programming language that frees
> =A0 you from the burden of clarifying your ideas." - xkcd
>



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

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