Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Suggestion for use of Void
Message-ID: <1037@tetrauk.UUCP>
Date: 30 Nov 90 12:23:14 GMT
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 82

This newsgroup seems to have been very quiet recently - is Frank Caggiano the
only person (apart from me) writing Eiffel code?  Just to liven things up, here
is an idea for discussion.  (For the record, I thought Frank's stuff on X
resource management looked good and is a much needed facility.  I've saved it
for later since I'm not doing any X windows work right now.)

(BTW, did my posting on an enhanced exception class finally make to the net?
Our feeder site had some serious disk problems recently and a lot of stuff got
lost.  I would have expected some comment on the article & I haven't received
any - could anyone who's seen the article let me know.  If I get no replies I
will try and post it yet again.)

This article concerns the use (or lack of) the Void keyword in Eiffel.  I
believe it would be useful if the language supported Void as a "stand-alone"
keyword, representing of course a void reference.  While the language currently
has .Void and .Forget as pseudo features representing test and assignment
against a void value, it doesn't have a construct to pass a literal void
reference as an argument to a routine.  I now have a number of classes with
features which will accept a void argument and still behave sensibly;  the
pupose of the parameter is to supply optional information.  A particular
example is an exception object which can be initialised with arbitrary comment
text at the point of creation:

	local
		excep: MSG_EXCEP ; code: INTEGER ;
	do
		...
		if <some condition> then
			excep.Create (code, "Report this error") ;
		...


When used in a context in which no information is relevant, it is necessary to
declare a local string variable to provide a syntactically valid void
reference:

	local
		excep: MSG_EXCEP ; code: INTEGER ; null_str: STRING ;
	do
		...
		if <some condition> then
			excep.Create (code, null_str) ;
		...
(I specifically want a void reference, not a blank string)

It would be far cleaner to be able to write:

			excep.Create (code, Void) ;

A Void of course conforms to any class type, so it is syntactically valid
anywhere an object reference is required.

This raises the interesting issue of forms such as:

	obj_ref := Void			equivalent to	obj_ref.Forget

	if obj_ref = Void then		equivalent to	if obj_ref.Void then

These would clearly be valid, and as alternate forms are they preferable to the
current style of pseudo features?  My personal opinion is that they are, since
I find the pseudo feature concept in Eiffel one of its less elegant
characteristics.  Given the opportunity, I would in fact replace the following
as well:

	a.Create (params)		a := Create A_CLASS (params)

	a.Clone (b)			a := b.Clone

In the latter case, the feature deep_clone which is in ANY works the same way
as the right-hand version, making the different clone operations incompatible
in the current version.  In fact if deep_clone were called "duplicate", it
would I believe support the "duplicate" feature of the STRING class without any
redefinition.

Does anyone else have a view on this?  Does anyone care?
Is there anyone out there?  Is the Eiffel tower still standing?

-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan


Brought to you by Super Global Mega Corp .com