Hi,
Is function overloading allowed in Lisp?
I jsut saw the following code:
(defmethod draw-pid-curve ((circle pid-circle) stream color)
......)
(defmethod draw-pid-curve ((arc pid-arc) stream color)
......)
Is it function overloading?
Thanks!
Jim
On Wed, 2 Aug 2000 19:29:01 -0700, Coby Beck wrote:
> "Jim Cheng" <·······@yahoo.com> wrote in message
> ······················@yahoo.com...
>> Hi,
>>
>> Is function overloading allowed in Lisp?
>>
> yes.
No.
>> I jsut saw the following code:
>>
>> (defmethod draw-pid-curve ((circle pid-circle) stream color)
>> ......)
>> (defmethod draw-pid-curve ((arc pid-arc) stream color)
>> ......)
There's only one function. You can't, for example, have
(defmethod draw-pid-curve ((square whatever) stream) ...)
i.e., without the third argument, as you could with C++-style
overloading. OO method dispatch is something different.
--
When C++ is your hammer, everything looks like a thumb.
-- Steven M. Haflich
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley <·······@actrix.gen.nz> writes:
> On Wed, 2 Aug 2000 19:29:01 -0700, Coby Beck wrote:
>
> > "Jim Cheng" <·······@yahoo.com> wrote in message
> > ······················@yahoo.com...
> >> Hi,
> >>
> >> Is function overloading allowed in Lisp?
> >>
>
> > yes.
>
> No.
sort of. since lisp is much less picky (by default) about the
argument types, you can get away with a single function. it's not
function overloading per se, but kind of like it. e.g.,
(defun square (x)
(* x x))
will do the right thing for integers, double-floats and complex
types.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam <········@ne.mediaone.net> writes:
>
> Paul Foley <·······@actrix.gen.nz> writes:
>
> > On Wed, 2 Aug 2000 19:29:01 -0700, Coby Beck wrote:
> >
> > > "Jim Cheng" <·······@yahoo.com> wrote in message
> > > ······················@yahoo.com...
> > >> Hi,
> > >>
> > >> Is function overloading allowed in Lisp?
> > >>
> >
> > > yes.
> >
> > No.
>
> sort of. since lisp is much less picky (by default) about the
> argument types, you can get away with a single function. it's not
> function overloading per se, but kind of like it. e.g.,
I think of "overloading" as connoting "allowing more than one unrelated
function to share the same name and to be distinguished only by the argument
number and type".
What CL has is not "overloading" though is easily confused with that.
It has "genericity". Genericity is NOT more than one conceptual function;
it is the same function, implemented for multiple types. For example,
SQRT could be implemented as a generic function by writing methods on the
types of its possible args. That wouldn't mean it didn't do the square root
thing in any case.
CL does some minimal checking to make sure argument signatures are the same,
but cannot check your conceptual intent. For example, the awful overloading
of 3+4=7 and "foo"+"bar" => "foobar" could be simulated in CL on a PLUS
generic function, but it would be wrong to do so. You're really on the honor
system here.
Kent M Pitman wrote:
>
> Johan Kullstam <········@ne.mediaone.net> writes:
>
> > sort of. since lisp is much less picky (by default) about the
> > argument types, you can get away with a single function. it's not
> > function overloading per se, but kind of like it. e.g.,
>
> I think of "overloading" as connoting "allowing more than one unrelated
> function to share the same name and to be distinguished only by the argument
> number and type".
In Java I tend to use it to simulate &optional, so in this case the
functions aren't unrelated.
Carl Gay <·······@mediaone.net> writes:
> Kent M Pitman wrote:
> >
> > Johan Kullstam <········@ne.mediaone.net> writes:
> >
> > > sort of. since lisp is much less picky (by default) about the
> > > argument types, you can get away with a single function. it's not
> > > function overloading per se, but kind of like it. e.g.,
> >
> > I think of "overloading" as connoting "allowing more than one unrelated
> > function to share the same name and to be distinguished only by the
> > argument number and type".
>
> In Java I tend to use it to simulate &optional, so in this case the
> functions aren't unrelated.
Yep, I do, too. And one might even make a credible case that
foo (int x, String y)
foo (int x)
foo (String y)
foo ()
were "all args", "optional second", "optional first", and "optional both".
The risk of confusion here is great, but it's possible to claim some uses
are reasonable. Especially if the shorter versions just recall the longer
with missing args...
But I really meant more like "+" where string concatenation is not
like addition, since one is commutative, for example, and the other is
not.
Even the Lisp signature-matching stuff is too restrictive in some cases and
there are places I'm trying to do the same function but can't quite write it
as I like because of overzealous congruency requirements. (I think it's
something with &key vs &rest that was overdone, but I don't recall.) These
things are poor substitutes for an "intent checker". Presumably somewhere
around MS/Word release 9.0 we'll have "intent checkers" built into text
editors and then we won't need to worry so much about the language itself...