|[30 earlier articles]|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-11-01)|
|Re: Polymorphism vs. Overloading email@example.com (1994-11-01)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-11-02)|
|Re: Polymorphism vs. Overloading bimbart@CS.kuleuven.ac.be (Bart Demoen) (1994-11-02)|
|Re: Polymorphism vs. Overloading email@example.com (1994-11-01)|
|Re: Polymorphism vs. Overloading firstname.lastname@example.org (1994-11-09)|
|Re: Polymorphism vs. Overloading email@example.com (1994-11-09)|
|From:||firstname.lastname@example.org (Frank Adrian)|
|Organization:||Europa |||| Portland, OR|
|Date:||Wed, 9 Nov 1994 06:08:03 GMT|
: email@example.com (Gabriela O. de Vivo) writes:
: >>>At some point a question raised about the exact difference between
: Polymorphism and Overloading.
: It's sort of like Outcome Based Education vs "Back to the Basics" --
: They're essentially the same thing except that one is defined as good
: while the is other evil.
I think this does hit the proverbial nail on the head. In an abstract
sense, when we are talking about overloading/polymorphism/what have you,
we are talking about a NAME RESOLUTION problem. In any of these cases,
we have a (meta-) function ID X TYPE* -> FUNCTION. The various restrictions
of these name resolution functions are often given highly politically
(and marketing) charged "goodness" arguments, when most are just
safety/flexibility and early/late binding tradeoffs. Whatever fancy way
you want to slice and dice your restriction classes of this name resolution
function, the underlying mechanism is still the same.
Frank A. Adrian ancar technology Object Analysis,
firstname.lastname@example.org PO Box 1624 Design,
Portland, OR 97207 Implementation,
Voice: (503) 281-0724 and Training...
FAX: (503) 335-8976
Return to the
Search the comp.compilers archives again.