Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!cmcl2!esquire!yost
From: yost@DPW.COM (David A. Yost)
Newsgroups: comp.lang.eiffel
Subject: Re: Initialising data structures
Message-ID: <2769@esquire.dpw.com>
Date: 1 Nov 90 20:15:21 GMT
References: <931@tetrauk.UUCP> <437@eiffel.UUCP>
Reply-To: yost@esquire.UUCP (David A. Yost)
Organization: Davis Polk & Wardwell
Lines: 49

In article <437@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>As a final comment, it would be inappropriate to have C-like
>static initialization in an object-oriented context.  [because?] Initializing
>with literal values (integers, strings, ...) is only one possible case;
>in general one wants to initialize with arbitrary objects.

>The tuple facility, combined with the facilities for storing and retrieving
>persistent objects, should remove this problem.

I see two issues here:

1.  Syntax for instantiating unnamed complex objects

Emphasis on 'unnamed', not 'constant'.  Clearly it is
good to have syntax that can express unnamed constants.
It would be a pain to have to declare a temporary
variable and execute some run-time code every time you
wanted to use a number or string in the code.  The same
is true for more complex objects, and it's not really a
matter of whether they are made up of constants or not.
It's a nice thing to be able to instantiate an unnamed
object on the fly just as one does with numbers and
strings.  It appears that the new tuple mechanism only
helps for things like lists and arrays.

(C isn't a very potent straw man for your argument.
After all, in C you can only express unnamed complex
objects in initializations, not at arbitrary points
in the code, and all the elements must be constants.
Other languages do very well with unnamed complex
objects.)

2. Run-time code vs. compile-time data statements

In Eiffel, most kinds of initialization must be
expressed as run-time code.  This is nice as a
language simplification.  (Why have two ways of
expressing how to store data somewhere when you can
have just one?)  The only problem I see here is that
the compiler is not yet smart enough to optimize out
constant-initialization code and generate appropriate
compile-time data initialization statements.

I hope some day Eiffel compilers will do that.

 --dave yost
   yost@dpw.com or uunet!esquire!yost
   Please don't use other mangled forms you may see
   in the From, Reply-To, or CC fields above.