From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: Travis Griggs Subject: Re: OO, C++, and something much better! Date: 1997/01/28 Message-ID: <32EE2514.5F74@bmi.net>#1/1 X-Deja-AN: 212818702 references: <32E47B4B.56D9@concentric.net> <6PI998tV3RB@herold.franken.de> <5c4ab5$134$1@goanna.cs.rmit.EDU.AU> <01bc0c93$e6f282f0$c318b993@jarvisb> cc: krg@nfuel.com, rfazzari@ieee.org, fskorina@bmi.net content-type: text/plain; charset=us-ascii organization: Blue Mountain Internet mime-version: 1.0 reply-to: tkc@bmi.net newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.lang.eiffel x-mailer: Mozilla 3.01Gold (Macintosh; I; PPC) Date: 1997-01-28T00:00:00+00:00 List-Id: Bob Jarvis wrote: > As a Smalltalk developer there are times where I think I'd like to be able to > specify the class of a message parameter so that some level of "type > checking" could be done. Something like > > myMessage(String): parm1(String) parm: parm2(Magnitude) > > would indicate that myMessage should answer a String (or some subclass of > String), that the first parameter should be a String, and the second parameter > should be a Magnitude. It would be nice if this was optional - if no classes were > specified then the system shouldn't try to do any checking. > > However, as a Smalltalk developer I'm also aware that this isn't absolutely I agree, there have been times I thought this would be nice. The problem with this (as I see it) is that you just shot reuse a part. Create a MeasuredValue system (one that associates numerical magnitudes with units) and you can't throw your new (and very powerful) numbers at your message. Create a set of objects which represents algebraic math. Same thing. Create a UserMessage (for internationalization) and throw it in as your String parameter. Again, kaboom. I use *these* examples, because I have actually done implementations of each. And in each case I have been nothing less than delighted at the polymorphic nature of the system and how well my new stuff interfaced with the already existing class library. To really be able to retain this flexibility and still add the type checking you propose you could take different approaches: 1) You could add the ability to do OR type declarations (i.e. a type is UserMessage OR String). 2) You could add multiple inheritance, so that if you need to throw an Algabraic object at a method that expects a Magnitude, you just add Magnitude to the Algabraic objects list of super classes. 3) You could come up with a typing system that specifies interface (i.e. an object of a given interface is garanteed to respond to messages a, b, and c), rather than class implementation. Each has problems though: 1) assumes that you know (up front) all of the class types that will be thrown at a method. This doesn't happen. How am I supposed to know when I design my object (with its typed method(s)) that in a year from now I will write yet another numerical object that encodes error propogation (e.g. Geometric Dimensioning and Tolerancing)? BTW: I've done this one too - dont want anyone to think I'm making up hypothetical examples here. 2) MI for purposes of reuse is like one of those calculus functions we all hate (i.e. as the limit approaches infinity type of thing). IOW, as the set of objects approaches being generically reusable system wide, all classes end up inheriting from each other. Of course, this is more than MI, this is Circular inheritance! (i.e. in one place Integer needs to inherit from MeasuredValue to be used, but in another place MeasuredValue needs to be inherit from Integer). 3) typing the interface (as opposed to the class representation) is somewhat better, but it still has problems. In addition to typing the interface, I've got to make sure that these expected methods return values that have typed interfaces (i.e. method 'a', which incoming parameter must respond to, must return an object that responds to messages c, d, e). And what if two objects implement method 'a' with totally different behaviors and intended uses (e.g. both Magnitude and Set respond to +). -- Travis or Kerrin Griggs Key Technology (509) 529-2161 tkc@bmi.net (509) 527-8743