Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bloom-beacon!husc6!bunny!dcr0
From: dcr0@bunny.UUCP (David Robbins)
Newsgroups: comp.lang.eiffel
Subject: Re: Typing question in eiffel
Message-ID: <6843@bunny.UUCP>
Date: 24 Apr 89 13:47:27 GMT
References: <DLD.89Apr21161427@F.GP.CS.CMU.EDU>
Organization: GTE Laboratories, Waltham, MA
Lines: 51

From article <DLD.89Apr21161427@F.GP.CS.CMU.EDU>, by dld@F.GP.CS.CMU.EDU (David Detlefs):
> Somewhere in the book there is reference to the "golden rule" of the
> Eiffel type system: on page 223, it says
> 
> 	"Once a system has been compiled, there is no risk that a
> feature will ever be applied at run-time to an object that is not
> equipped to handle it."
> 
> This is a laudable goal.  My question is how this can be reconciled
> with the "orthoganility of information hiding" -- on page 272, we find
> that a descendant class B is allowed not to export to clients a
> feature f that its ancestor A does export.  Now, if we have an entity
> x of static type A and dynamic type B, is x.f legal?  If so, does
> this make sense, and why?  It seems to me that if you create a B,
> allowing f to be invoked could violate B's representation invariant.
> 
> (Consider a type A that is basically an integer.  It is created with
> value 0, and offers "incr" and "incr_by_2" operations.  Its rep
> invariant is that it is > 0.  If B inherits from A, but only exports
> the create and incr_by_2, its invariant is that it is > 0 and
> divisible by 2.  If you ever invoke incr on a B, you violate its invariant.)
> 
> Can anyone clear this up for me?  Thanks.

Well, I'm not sure we can exactly clear this up, but I can shed a little light
on the subject.  There was some discussion related to this issue on the
net a few weeks ago, and Bertrand Meyer pointed out that the current release
of Eiffel (2.1 at the time) was in fact unable to properly enforce the
"golden rule" in the particular circumstances you bring out.  His clear
intent was indeed that Eiffel should not permit the invocation, by a client,
of an operation that was inherited but not exported.  He also said that he
was working on a technique whereby this restriction could be properly enforced
by the compiler, but he gave no details.  I don't recall whether proper
detection of violations of this nature was promised for release 2.2 of Eiffel.

I know from my own experiments that you could write a pair of Eiffel classes
as you suggest, compile them without error, and invoke the incr operation on
an instance of type B.  Indeed, this can lead to undesirable behavior, and
your only recourse is to carefully hand-check your program for violations
of this nature.

I look forward to the time when Eiffel can catch -- either at compile time or
at run time -- violations of all of its rules.

Perhaps someone else on the net can answer this more definitively than I can,
but I hope this is of some help.
-- 

Dave Robbins                    GTE Laboratories Incorporated
drobbins@gte.com                40 Sylvan Rd.
...!harvard!bunny!drobbins      Waltham, MA 02254