Re: OO puzzle

[Jeffrey L Straszheim <stimuli@shadow.net>]

Brian Rogoff wrote:

> On Thu, 30 Dec 1999, Jeffrey L Straszheim wrote:

> > I have mixed feelings. I've used covariance, and it turns out that I
> > found it generally useful, even while the holes in the type system
> > bothered me on a basic level.
 
> Kind of like "conservative" (inaccurate) garbage collectors. You know its
> wrong even though it seems to work most of the time.

Fair enough. However, with covariance -- at least if it is used
wisely, which means not used much -- I can be certain that my program
is, ultimately, correct and will not make an invalid catcall. With
an inaccurate GC, I can write a correct progam, but have it bomb
when deployed because of faults in the GC.
 
> I preferred Sather's approach, though I admit contravariance isn't
> "useful" there were acceptable workarounds for covariance.
 
> > At a certain abstract level, Ada has a similar issue, in that I can
> > declare a subtype and, as it turns out, have no formal guarantee that
> > I won't violate its constraint. In both situations one could make
> > the effort to prove that a violation will not occur, but in neither
> > case does the language formally guarantee it.
 
> This is really not the same, as Ada subtypes aren't like Eiffel
> subclasses. Its more appropriate to compare Ada subtypes with
> array bounds checking and the like.

Of course it's not the same: no two different things are ever the
same. The point is Ada allows me to do this:

In some package specification:

 function Some_Opaque_Library_Function (Param: Integer) return Integer;

In my code:

 The_Largest_Fred : constant := 135;
 subtype Fred is range 0 .. The_Largest_Fred;

 A_Variable       : Fred := 0;
 Another_Varialbe : Fred;

 begin

   Another_Variable := Some_Opaque_Library_Function (A_Variable);

...

Now, nothing guarantees that the constraint for subtype Fred won't
be violated here, causing a runtime fault. (BTW, this is the sort
of place where DBC really helps, but I won't belabor that point.)

Now, one can debate whether this is a (potential) type error. If
so, the debate becomes a semantic one and a waste of time, but
let me just say that by some definitions of type, this is indeed
considered a type error. Again, I'd prefer not to belabor the point.

So, here is my point: catcalls are one area where Eiffel lets
its programmers shoot themselves in the foot. There are a few others,
namely the subclassing rules for generics (yuck), but all in all
I've found these problems easy to avoid, more so than avoiding,
say, buffer problems in C. I'm just learning Ada now, so I have
limited experience with it, but I suspect that I won't have problems
with its "gotchas" either. At least it seems so at first glance.
 
> It is interesting that in lots of modern languages with sophisticated type
> systems the type checking is very hard, sometimes even undecidable. C++
> with its templates come to mind, but OCaml's module system also has such
> problems.

-- Jeffrey Straszheim          
-- Systems Engineer, Programmer
-- http://www.shadow.net/~stimuli
-- stimuli AT shadow DOT net