Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Re: Continued discussion of object model in Eiffel
Keywords: Eiffel c++ object
Message-ID: <1991Feb14.064433.21212@tukki.jyu.fi>
Date: 14 Feb 91 06:44:33 GMT
References: <70548@microsoft.UUCP>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 86

In article <70548@microsoft.UUCP> marklan@microsoft.UUCP (Mark LANGLEY) writes:
> ...
>distinction in the Eiffel object philosophy vs the C++ object 
>philosophy.
> ...
>It's interesting that C++ which has the avowed philosophy of 
>"never add run-time cost" has the more expensive object model.  
>For example, if you inherit a lot of stuff which has constructors, 
>you can find that you spend a lot of time waiting for things to 
>initialize.  [...]

And when you have "ended the programme" (exited 'main'),
it can still spend a lot of time waiting for things to finalise
(calling the destructors of objects).

However, I think that the possibility to define constructors and
destructors is an advantage of C++ over most other OOPL's.
In some other design decisions of that language, run-time efficiency
has indeed triumphed over object orientation, with sad results.
(But enough with that, this group seems to be comp.lang.eiffel.)

> ...
>Since Eiffel requires that you do your own initialization of baseclasses,
>I would like to see Eiffel extended to allow invocation of features without 
>having to rename them into the current class; renaming seems awkward, error 
>prone, and misleading.  [...]

Agreed!

> ...
>Now about that new creation syntax: I don't think I like it.  [...]

I think the reasons for the change were very logical.

>In the next major release of Eiffel from ISE you will be able to say:
>
>	local
>		x :someclass;
>	do
>		x!
>	end
>
>In the first place, forcing the user to do x! is a cruel hoax.  [...]
> ...
> [...]  (Has eliminating void references been been suggested before? it seems 
>like such an obvious thing...)

Keep in mind that variables and objects are totally distinct things
in languages such as Eiffel!  Often the first thing done with a variable
is assigning an existing object to it.  The automatic creation of a new
object would then be labour lost, and the amount of labour may not be
negligible if the object is large and complex.

A more serious difficulty for this proposal appears with directly
or indirectly recursive classes.  How should automatic initialisation
be arranged in such cases?  Example (syntax may not be 100% correct):

class Person export ... feature
        mother: Person;  father: Person;  spouse: Person;
        children: Person_set;
        ...

Note also that there may be a valid meaning for a variable staying Void:
in this example e.g. that a person really has no spouse.

>Version 3's new syntax allows you to call a descendent (not ancestor --
>that's what I thought too) function on the current object under
>construction as follows.
>	
>	x!DescendentFeature!mycreate(10,20);
>
>The idea of calling a descendent class is barbaric:  It encourages fuzzy 
>reasoning about the type system; It's imprecise and it's error-prone.  You 
>can't call a descendent function at any other time in an object's life, why 
>should it be legal at creation time?
> ...

That does sound ugly indeed!

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)