Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!enea!helios!kim
From: kim@helios.enea.se (Kim Walden)
Newsgroups: comp.lang.eiffel
Subject: Re: Multiple creation routines.
Message-ID: <KIM.90Dec17113023@helios.enea.se>
Date: 17 Dec 90 10:30:23 GMT
References: <4106@tantalum.UUCP> <1045@tetrauk.UUCP> <4212@tantalum.UUCP>
	<1051@tetrauk.UUCP> <462@eiffel.UUCP> <1057@tetrauk.UUCP>
Sender: kim@enea.se
Organization: Enea Data AB, Sweden
Lines: 71
In-reply-to: rick@tetrauk.UUCP's message of 14 Dec 90 10:02:38 GMT

In article <1057@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:


>   I have one query though.  The proposed syntax allows an object to be
>   created using the form:
>
>	   x !!
>
>   meaning create an "empty" object.  It may be quite incorrect for an
>   object of the class in question to be in such a state - i.e. the invariant
>   would be violated.  However, there seems to be nothing syntactically to
>   prevent a client program from doing this, so correctness would rely
>   entirely on invariant checking in the target class.  This is a retrograde
>   step from the current situation, where a call to the create routine at
>   least has to provide the proper arguments.
>
>   It would seem that the "creation" clause needs some way of specifying
>   whether a default creation call is valid or not.

Quoting from Bertrand's proposed change:

>>    For a class which has no creation procedure (meaning that the default
>>    initializations are sufficient to ensure the invariant), the syntax
>>    becomes simply
>>	x!!

So a default creation call is never valid when the creation clause of the
corresponding class is non-empty.   The compiler will force the user to
specify one of the listed creation routines (with proper arguments, if any).

This is reasonable, since the presence of a creation routine normally means
that some additional initial actions are necessary to ensure the invariant.

In rare cases where you want to allow a default creation call as an
alternative to the specified creation routines (knowing that the invariant
will be satisfied anyway), you will just have to use an empty routine.

Using e.g. the proposed feature `none' of class ANY (which just returns a
void reference) allows this without much ado:

	class C export ...
	creation
		f1, f2, none
	...
	end class C

in the client:
	...
	x: C;
	...
	x !! f1 (...); ... x !! f2 (...); ... x !! none; ...

(Ok, since the specified creation routines can have different numbers
and types of arguments.)

This seems much clearer than mixing the two forms, and convinces
both the compiler and the human reader that the occasional default
object creation is indeed intensional.

(Purists who don't like using a function for doing nothing can e.g.
add an empty procedure `default' to class HERE, or maybe ISE should
add it to ANY.)

Note that I am only talking about the rare cases here.  Most classes will
have empty creation clauses, and then the short form  x !!  is applicable.



Kim Walden
Enea Data, Sweden
kim@enea