Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!princeton!udel!rochester!rit!ultb!mbr6316
From: mbr6316@ultb.isc.rit.edu (M.B. Robin)
Newsgroups: comp.lang.eiffel
Subject: Questions
Message-ID: <1822@ultb.isc.rit.edu>
Date: 22 Dec 89 07:41:16 GMT
References: <1989Dec19.165420.7477@cs.tcd.ie>
Reply-To: mbr6316@ultb.isc.rit.edu (M.B. Robin)
Organization: Information Systems and Computing @ RIT, Rochester, New York
Lines: 54

Hello. I am a new Eiffel user, and I have a few questions and comments.
Firstly, I am by no means an Eiffel expert - I have not been able to
spend as much time with the system as I would like due to the current
state of computing resources available to me. I have, however, had some
limited direct experience with Smalltalk, C++, and Flavors. All in all,
I am impressed with the thought that has gone into the making if the Eiffel
system. With that said, I have a few comments....

One thing that bothers me is the use and syntax of Clone, Copy, Create, and
Forget.  In Eiffel "a.print" sends the "print" message to object "a".
(Excuse the Smalltalk terminology...)  If "a.Void" is true, as it is
before creation, then "a.Create" makes little sense to me - because
"void" does not respond to "Create" - ie, there is nothing to send the
"Create" message to.  I would like to see "a := T.create"
(where T is the type of "a") or "a := (like a).create" or 
"a := a.class.create" - where the "a.class" part is evaluated at 
compile time. I know that Classes are not run-time entities in Eiffel, 
but these constructs are consistant with user-level Eiffel semantics, 
and are easy to understand. (To me anyway...) 

The latter brings up my second point, which applys to Clone, Copy,
and Forget as well.  Instead of "a.Clone(b)", for example, I would
like to see "a := b.clone". Why? Although the former is a syntacticly 
correct Eiffel expression, it behaves in a non-standard way. It is not
clear why "a.Clone(b)" should be able to magically modify the entity "a". 
There is no way to achieve this oneself in Eiffel, nor should there be.
The message can change the state of the object referenced by "a" - but
should not be able to do an assignment to an entity "under the hood."
(That is, of course, unless the *object* itself was changed - but this 
would affect all references to the object, however - ie, in Smalltalk :
"a become: b copy.") In summary, "a.<anything>" should not change the
value of the entity "a" - only "a := <something>" should, as one would
expect.

Note that I think it should be possible to add this behavior to
Eiffel by adding to the top of the class hierarchy "Result.clone(Current)",
as the feature "clone". (So "a:=object.clone" <=> "a.Clone(object)" )

Actually, I do understand (I think) why some of these issues have been
resolved as they have - but I would welcome comments nonetheless.

I don't want to say anything else for fear that I am misunderstanding
a key Eiffel concept. I hope my comments aren't too off the mark - and
forgive me if they have been discussed previously. (Well, I *could*
ask why semicolons are statement separators in Eiffel, and not terminators,
as they *should* be.... :-) ) 

I wish nothing but success for Eiffel and its (her?) users - and
have a merry Christmas. (or whatever it is that you do...)
____________________________________________________________________________
    Michael Robin, 315 Fairwood Circle      mbr6316@ritcv.rit.edu
    Rochester, NY, 14623                    ...rochester!ritcv!mbr6316
	"Saru mo ki kara ochiru."
_____________________________________________________________________________