Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh
From: mccaugh@s.cs.uiuc.edu
Newsgroups: comp.lang.eiffel
Subject: Re: Questions
Message-ID: <231500002@s.cs.uiuc.edu>
Date: 3 Jan 90 17:38:24 GMT
References: <1822@ultb.isc.rit.edu>
Lines: 49
Nf-ID: #R:ultb.isc.rit.edu:1822:s.cs.uiuc.edu:231500002:000:2507
Nf-From: s.cs.uiuc.edu!mccaugh    Jan  3 02:17:00 1990



> In Eiffel "a.print" sends the "print" message to object "a". 
> 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.  

 Yes, but isn't that just the appropriate condition to Create object "a"?
 If "a.Void" were false, wouldn't an attempt to Create "a" be redundant?
 Compare this with applying 'fopen' with mode = "w" to a non-existent file
 in C: If it were regarded as an error, how could such a file get written to
 the first time (which presumably explains why it gets "created on demand")?

> I would like to see "a := T.create"
> (where T is the type of "a") or "a := (like a).create" or ...

 But you suggest above (via: "a.Create") that the syntax is: <object>.Create,
 not <class>.Create: aren't you using Create to instantiate objects of a class?
 

> 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.

 But this is reminiscent of the above case: you wanted to be able to say:
 "a := T.create" before an object "a" existed to be assigned; "a.Create"
 is a classic instance of wanting "to change the value of the entity 'a'"
 in a most significant way (from Void to non-Void).


> 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.... :-) ) 

No, I respect your comments and appreciate your interest in Eiffel.

 Scott McCaughrin (I commend, not condemn.)