Right. We're talking about how to emulate object orientation with a library.
One of the biggest reasons I don't like this is that programmers always seem to take shortcuts and bypass the library when it doesn't do quite what they want. I see this all the time with Fileman. Not infrequently, a piece of functionality would be easy to implement with a cross-reference or similar mechanism, but this isn't possible because a review of the code reveals that the files are frequently updated through direct global sets. It's not supposed to happen, but it does. --- 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 > === 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
