It is a different style of typing Java is a strong typed language but can use polymorphism because the type is an object not a primitive.
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 Ruben Safir Sent: Friday, August 26, 2005 3:21 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Re: All about programming On Thu, 2005-08-25 at 17:39 -0400, Kevin Toppenberg wrote: > Actually, I think I was on track after all. > I'll look at the link, but I'm fairly certain I'm correct. I've taught it for 9 years. The idea that something can't be polymorphic because of typing is a little weird. Strong typing is one of the major problems that must be overcome with polymorphism since the data types of the arguments prevent in C and strong typed languages to be fed the function. In a structured programing language like C, a function is strictly defined and without some pointer magic, always behaves exactly the same. BTW - I don't know how mumps defines indirection, but its not the same as the indirect reference. Ruben > I think was Ruben was talking about is function-calling morphism (i.e. > an object can have multiple functions with the same name, and the one > which is called is determined based on the pattern of the passed > parameters.) > > This link describes polymorphism similar to what I was posting. > > http://www.cnread.net/cnread1/dnwl/cxsj/c/bcb/021.htm > > Kevin > > > On 8/25/05, Aylesworth Marc A Ctr AFRL/IFSE <[EMAIL PROTECTED]> wrote: > > 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 > > > > > ------------------------------------------------------- > 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
