Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!cook
From: cook@hplabsz.HPL.HP.COM (William Cook)
Newsgroups: comp.lang.eiffel
Subject: Re: Static typing for Eiffel
Summary: what is a type, anyway?
Keywords: The full paper (at long last) - PART 1 (of 2).
Message-ID: <3633@hplabsz.HPL.HP.COM>
Date: 21 Jul 89 16:34:41 GMT
References: <176@eiffel.UUCP>
Organization: Hewlett-Packard Laboratories
Lines: 57



In my last note (on which news has been oddly silent, although I have
gotten some nice mail messages) I argued that there are some
insecurities in the Eiffel type system and made a proposal for fixing
them.  Bertrand Meyer then posted the reply "Static typing for
Eiffel".  I would like to reply to his proposal.

One way of looking the insecurities in Eiffel (not necessarily the
best way) is that certain combinations of assignment of subclass
objects to superclass variables (basic uses of subtype polymorphism
essential to OOP) in combination with certain feature accesses can
lead to run-time errors in the presence of genericity, feature type
redefinition, and association types.  I suggested that in some cases
redefinition is not safe, and in others that the assumption of
assignment compatibility is unreasonable.  Dr.  Meyer claims that
these are conceptually correct, but that the use of certain
assignments and a feature accesses in the same program are invalid.  I
have two comments.

First, it seems pretty clear to me that most features are accessed
somewhere in the program.  Otherwise why would they be there.  Thus we
may focus on the use of "certain assignments", namely those that
assign a subclass object to a superclass variable in those situations
that I pointed out where unreasonable.  If a single assignment of this
form appears in the program, then the program will not compile and an
error will be signalled.  Yet this is exactly what I propose:  to make
the assignment illegal by eliminating the erroneous conformance
relation that made it apparently legal in the first place.

Second, it seems apparent to me that the kind of assignments used in a
class should not be part of its "type" but should be encapsulated
within its implementation.  My proposal defines the legality of
assignments in terms of types, which are something the user can be
expected to know and understand.  Dr.  Meyer's proposal is based on
supposedly hidden information, namely the assignments a class "in fact
uses" as opposed to "is allowed to use".  Thus rewriting the
implementation of a class (e.g. to improve efficiency) may cause all
programs based on it to break if it happens to use a different set of
assignments.  This violates the goal of encapsulated implementation.

I think that if you rewrote the program, or planned it in advance at
the design stage, so that the types where an accurate description of
what you were trying to do, then the program would have better
structure, be more robust, and easier to teach/maintain.

I also can't believe that the LIST example in section 4.3, the
"rationale for the redefinition rule" is very good evidence.  It seems
to me that LISTS are naturally generic, and if one doesn't realize
this at first attempt it would be a good idea to redesign as soon as
possible rather than building more code on a faulty design until it
becomes really difficult to change the situation.  This also brings up
the possibility that a non-generic type (the first attempt) could
reasonably conform to a generic type (based on the redesign) and thus
ease the transition...

-william cook