mgardi@watdcsu.waterloo.edu (M.Gardi - ICR) (03/31/89)
I have a few more questions regarding the PC implementation of OO products. Does anyone out there develop on a machine,say the SUN, running UNIX, and then port the product to (in our case), a PS/2? We have to support at least a model 50. Is anyone developing for PC's that are not 386 machines or the equivalent? On a different note, Using C++, (and an eiffel reply would be nice), could one create static instances of a class? This goes back to whether classes are objects etc. The circumstance would be if your program internally wanted to create say 3 instances of a certain class, and always wanted to do this. I would like these to be there all the time, and not created at run time. I guess the second question is whether or not one can automatically construct sub-classes when a base class is constructed. If they are created in the base class constructor, one would have to change this routine everytime a new subclass was added. Hope I am not way off the wall here, and making some type of sense! p.
mbr6316@ultb.isc.rit.edu (M.B. Robin) (12/22/89)
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."
_____________________________________________________________________________mccaugh@s.cs.uiuc.edu (01/04/90)
> 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.)
bertrand@eiffel.UUCP (Bertrand Meyer) (01/11/90)
In article <1822@ultb.isc.rit.edu>, mbr6316@ultb.isc.rit.edu (M.B. Robin)
raises a number of interesting questions with respect to Create, Clone,
Forget etc.
We (the design and implementation group at Interactive) essentially agree
with his (?) comments. There is indeed a need to separate operations
on references from operations on objects. We think that we have solved
all these issues, for the moment on paper, as part as the ongoing
language cleanup. This is all described in the version of
``Eiffel: The Language'' to be published soon by Prentice-Hall.
--
-- Bertrand Meyer
bertrand@eiffel.com