Don't forget about generics. http://www.artima.com/intv/generics.html
/David. David Sommers, Architect | Dialog Medical -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruben Safir Sent: Thursday, August 25, 2005 5:01 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Re: All about programming 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
