Related articles |
---|
[30 earlier articles] |
Re: Polymorphism vs. Overloading bill@amber.ssd.csd.harris.com (1994-11-01) |
Re: Polymorphism vs. Overloading drichter@pygmy.owlnet.rice.edu (1994-11-01) |
Re: Polymorphism vs. Overloading bevan@cs.man.ac.uk (1994-11-02) |
Re: Polymorphism vs. Overloading bimbart@CS.kuleuven.ac.be (Bart Demoen) (1994-11-02) |
Re: Polymorphism vs. Overloading monnier@di.epfl.ch (1994-11-01) |
Re: Polymorphism vs. Overloading nickb@harlequin.co.uk (1994-11-09) |
Re: Polymorphism vs. Overloading franka@europa.com (1994-11-09) |
Newsgroups: | comp.compilers |
From: | franka@europa.com (Frank Adrian) |
Keywords: | polymorphism |
Organization: | Europa |||| Portland, OR |
References: | 94-10-198 |
Date: | Wed, 9 Nov 1994 06:08:03 GMT |
: gdevivo@conicit.ve (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,
franka@europa.com PO Box 1624 Design,
Portland, OR 97207 Implementation,
Voice: (503) 281-0724 and Training...
FAX: (503) 335-8976
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.