Re: OO, C++, and something much better!

[Travis Griggs <tkc@bmi.net>]

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