I've heard this described as polymorphism, too. Purists would say it is
not polymorphism because it has nothing to do with runtime type, and
call it overloading instead. Others will say it's simply a different
kind of polymorphism (where behavior depends not upon the object being
operated upon, but instead how the method is invoked).
Interestingly, this kind of "signature polymorphism" is something you
CAN achieve in MUMPS, because you can always call a function with fewer
actual parameters than their are formal parameters.
--- Ruben Safir <[EMAIL PROTECTED]> wrote:
> A polymorphic function is one which changes its behavior depending on
> the type and number arguments it receives. It's useful because it
> is
> easier for the stupid humans to remember the Application programming
> interface. With polymorphism and operator overloading, you can do
> some
> amazing tricks for the stupid humans.
>
> At its most fundamental level a function and accessory function might
> behave like this
>
> bird->species("Bluejay"); #One Arguement is sent. The species has
> been
> set to Bluejay through method "species" which might also cause this
> instance of your object to change its color, size and other
> charactoristics
>
>
> $what_kind = bird->species; #no arguements
>
> print $what_kind; #stdout is BlueJay
>
> Ruben
>
>
>
> On Thu, 2005-08-25 at 16:43, Kevin Toppenberg wrote:
> > On 8/25/05, Greg Woodhouse <[EMAIL PROTECTED]> wrote:
> > > How do you achieve polymorphic behavior? A few ideas occur to me
> such
> > > as having a "CREATE" operator that sets the methods to the
> appropriate
> > > implementations for the runtime type. Another is to maintain a
> table of
> > > object IDs and classes and always have methods invoked through a
> common
> > > dispatch manager, but nothing really seems very clean.
> >
> > I am no OO expert. But I think that polymorphic behavior means
> that
> > if you have an object heirarchy like this:
> > Bird
> > +- Jay
> > +-Blue
> > +-Gray
> >
> > And then having two objects, one Gray and one Blue, placed into
> > variables p1 and p2. Then calling a ".chirp" function, would evoke
> > two separate functions--assuming that the two objects had been
> given
> > different chirp functions.
> >
> > Assuming that my understanding is correct, then I would probably
> set
> > up my "object" by creating the parent object, then calling the
> setup
> > procedure for each subsequent child in turn (i.e. merging the array
> > first with the parent object). Child functions would then
> overwrite
> > the parent's. Thus one might end up with an array-object that
> looks
> > like this
> >
> > Bird("sClass")="Aves"
> > Bird("bCanFly")=1
> > Bird("fncChirp")="w ""squawk"",!"
> >
> > Jay("sClass")="Aves"
> > Jay("sFamily")="Corvidae"
> > Jay("sOrder")="Passeriformes"
> > Jay("bCanFly")=1
> > Jay("fncChirp")="" <-- no behavior here.
> >
> > BlueJay("sClass")="Aves"
> > Bl;ueay("sFamily")="Corvidae"
> > BlueJay("sOrder")="Passeriformes"
> > BlueJay("sSpecies")="Cyanocitta"
> > BlueJay("bCanFly")=1
> > Bird("fncChirp")="w ""Jeer Jeer"",!
> >
> > GrayJay("sClass")="Aves"
> > GrayJay("sFamily")="Corvidae"
> > GrayJay("sOrder")="Passeriformes"
> > GrayJay("sSpecies")="Perisoreus"
> > GrayJay("bCanFly")=1
> > Bird("fncChirp")="w ""Ge-att Ge-att"",!"
> >
> > Then when I do this:
> >
> > p(1)=$name(GrayJay)
> > p(2)=$name(BlueJay)
> >
> > I can then use:
> > for i=1:1:2 xecute @p(i)@("fncChirp")
> >
> > Jeer Jeer
> > Ge-att Ge-att
> >
> > I think this shows how inheritence and polymorphism can be
> > implemented. But again, my teminology may be off.
> >
> > Kevin
> >
> >
> >
> > >
> > > Anyway, I remember that, and I think it's a good idea.
> > >
> > > --- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> > >
> > > > A while back I posted code that used globals to store
> object-like
> > > > data. Once can put functions (or references to functions) into
> a
> > > > string (stored in the object) and then executed with the
> "xecute"
> > > > command.
> > > >
> > > > Thus one could shoe-horn object orientated behavior from M
> > > >
> > > > Kevin
> > > >
> > >
> > >
> > >
> > > ===
> > > Gregory Woodhouse <[EMAIL PROTECTED]>
> > >
> > > "Design quality doesn't ensure success, but design failure can
> ensure
> > > failure."
> > >
> > > --Kent Beck
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software Conference &
> EXPO
> > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> > > Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> > > Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> > > _______________________________________________
> > > Hardhats-members mailing list
> > > Hardhats-members@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/hardhats-members
> > >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> > Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Hardhats-members mailing list
> > Hardhats-members@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Perfection is achieved, not when there is nothing more
to add, but when there is nothing left to take away."
-- Antoine de Saint-Exupery
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
