Here's a question for someone involved in the original CLOS design
process: what was the design rationale for requiring all methods
of a generic function to have congruent lambda lists? Why not
allow distinct method signatures a la Java/C++?
Thanks,
Erann Gat
···@jpl.nasa.gov
In article <····················@milo.jpl.nasa.gov>,
Erann Gat <···@jpl.nasa.gov> wrote:
>Here's a question for someone involved in the original CLOS design
>process: what was the design rationale for requiring all methods
>of a generic function to have congruent lambda lists? Why not
>allow distinct method signatures a la Java/C++?
Because CLOS is designed with the generic function as the point of
dispatch, not the object. If all the methods are supposed to be
implementing the same generic function, it makes more sense to require them
all to have the same basic calling sequence. In C++, on the other hand,
unrelated classes are more likely to have member functions with the same
name, since there's no generic function relating them; requiring them to
have the same signature would be inappropriate. C++ also has a general
notion of function overloading, which allows the same name to be used with
multiple signatures within the same class. IMHO, overloading is overrated;
because it's based on static types, it's easily replaced with distinct
function names (its primary benefit is when overloading operators rather
than functions, since it allows you to use concise, familiar operator
syntax for user-defined types).
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
On Mon, 26 Oct 1998 20:15:24 GMT, Barry Margolin
<······@bbnplanet.com> claimed or asked:
% multiple signatures within the same class. IMHO, overloading is overrated;
% because it's based on static types, it's easily replaced with distinct
% function names (its primary benefit is when overloading operators rather
% than functions, since it allows you to use concise, familiar operator
% syntax for user-defined types).
The name mangeling does that (provide different names) for the
linker's benefit. C++ still uses the C linker.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
Barry Margolin <······@bbnplanet.com> writes:
> In article <····················@milo.jpl.nasa.gov>,
> Erann Gat <···@jpl.nasa.gov> wrote:
> >Here's a question for someone involved in the original CLOS design
> >process: what was the design rationale for requiring all methods
> >of a generic function to have congruent lambda lists? Why not
> >allow distinct method signatures a la Java/C++?
>
> Because CLOS is designed with the generic function as the point of
> dispatch, not the object. If all the methods are supposed to be
> implementing the same generic function, it makes more sense to require them
> all to have the same basic calling sequence. In C++, on the other hand,
> unrelated classes are more likely to have member functions with the same
> name, since there's no generic function relating them; requiring them to
> have the same signature would be inappropriate. C++ also has a general
> notion of function overloading, which allows the same name to be used with
> multiple signatures within the same class. IMHO, overloading is overrated;
> because it's based on static types, it's easily replaced with distinct
> function names (its primary benefit is when overloading operators rather
> than functions, since it allows you to use concise, familiar operator
> syntax for user-defined types).
>
On top of that, if you do not need dispatching you can always
implement the different signatures (maybe a little more awkwardly) by
doing &key-&allow-other-keys tricks.
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 16, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it