[comp.lang.eiffel] `Create' type insecurity?

marku@cheops.eecs.unsw.oz (Mark Utting) (04/10/89)

After reading ``Object Oriented Software Construction'' and thinking about
how to implement a language such as Eiffel, I've come to the conclusion that
there may be a type insecurity in the design of Eiffel with regards
customised `Create' routines.  Experiments with the Eiffel 2.1 compiler
seem to confirm this.

The problem arises when a child class defines a customised create routine 
which has different arguments to its parent's create routine, and the
parent class attempts to call `Create' on an attribute (or local or result)
which is declared as `like Current'.  (Note that this *is* allowable -- there
is a similar example on page 269 of OOSC)

The trouble is that in the child class, the `Create' call will call the
child's create routine with arguments that are suitable for the *parent's*
create routine.  The number of arguments and the type of each argument can
be completely wrong for the child's create routine (reminds me of C :-)).

Is this a known problem in the Eiffel language?  Does anyone have any comments
or possible solutions?  The simplest solution that occurs to me is to ban
`Create' calls upon anchored variables.
How much existing code this would break I don't know!
A more sophisticated solution could perhaps ban a redefinition of `Create' iff
it would invalidate create calls on anchored variables from parent classes?

The following three classes illustrate this problem, and produce a runtime
precondition violation when the `next' routine is called:-

	class BUG1
	    -- Illustrates a possible insecurity in Eiffel: calling `Create'
	    -- on a redefined anchored attribute is not always type secure.
	feature
	c1:PARENT;
	c2:CHILD;
	Create is
	    do
	    c2.Create(10); -- this does a CHILD Create correctly.
	    c1 := c2.next; -- this calls a CHILD Create with no arguments!
	    end
	end -- BUG1

	class PARENT  export next
	feature
	next:like Current is
	    do Result.Create end 
	end -- PARENT

	class CHILD   export next  inherit PARENT
	feature
	teeth:INTEGER;
	Create(t:INTEGER) is
	    require t >= 1  -- children must have some teeth!
	    do teeth := t end
	end -- CHILD

Incidentally, this is not my usual layout style for Eiffel :-).


Mark Utting, Dept.Comp.Sci, UNSW, PO Box 1, Kensington, NSW, Australia 2033
   //		ACSnet,CSNET:	marku@cheops.unsw.oz
  //		BITNET/ARPA:	marku%cheops.unsw.oz@uunet.uu.net
\//		UUCP:		...!uunet!munnari!cheops.unsw.oz!marku
-- 
Mark Utting, Dept.Comp.Sci, UNSW, PO Box 1, Kensington, NSW, Australia 2033
   //		ACSnet,CSNET:	marku@cheops.unsw.oz
  //		BITNET/ARPA:	marku%cheops.unsw.oz@uunet.uu.net
\//		UUCP:		...!uunet!munnari!cheops.unsw.oz!marku