Polymorphism would be hard in Mumps because it is not strongly typed. The java implements it is to find out what class is calling it and then determines the correct function to call inheritance and polymorphism is close but is determined at different times (one at compile, one at runtime).
Thanks Marc Aylesworth C3I Associates AFRL/IFSE Joint Battlespace Infosphere Team 525 Brooks Rd Rome, NY 13441-4505 Tel:315.330.2422 Fax:315.330.7009 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Thursday, August 25, 2005 5:03 PM To: hardhats-members@lists.sourceforge.net Subject: [Hardhats-members] Re: All about programming 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 ------------------------------------------------------- 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
