OK. So I was quite a bit off on my understanding of the term polymorphism.
I have used this functionality often in c++, but I don't think that
Delphi/Pascal has it.
I guess what I was talking about, then, was simple inheritence. I
don't know if I could implement polymorphism with my scheme. One
problem is that there is no typing. I guess one could call in
intermediate function that counts the number of non-empty parameters
passed, and then use a table to figure out which final function to
call. But agin, it wouldn't be neat.
Kevin
On 8/25/05, 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
>
-------------------------------------------------------
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
