Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Initialising data structures
Message-ID: <437@eiffel.UUCP>
Date: 30 Oct 90 18:45:00 GMT
References: <931@tetrauk.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 51
A very simple extension will be present in version 3 and should
address the problem pointed out by Rick Jones. The Kernel Library
will contain a class TUPLE [T] describing finite sequences of objects
of type T, with arbitrary length. (This also addresses cases in which
a routine needs an argument list of variable size.)
This class is straightforward and its interface similar to
that of LIST, LINKED_LIST etc. It can in fact be written
in the current language. The only syntactic extension
is support for manifest constants of tuple type:
giving TUPLE a status similar to that of STRING (``normal''
class, but with special syntax for manifest constants).
Classes such as ARRAY will have procedures for initializing
from a tuple, e.g.
a.load (, 3)
where the second argument is the starting position.
A note on initialization in the current state of the language/environment:
in many cases it is useful to rely on the persistence facilities
to avoid re-executing initialization code. In the example quoted
by Mr. Jones, one may consider having two systems: an initialization system
that creates the data structures and ends its execution with
x.store (f)
and the ``real system'' which begins by loading the initialized data
structures by executing
x.retrieve (f)
instead of the actual initialization code.
As a final comment, it would be inappropriate to have C-like
static initialization in an object-oriented context. Initializing
with literal values (integers, strings, ...) is only one possible case;
in general one wants to initialize with arbitrary objects. However, as
Mr. Jones points out, the simple case of literal values is currently not
very elegantly handled. The tuple facility, combined with the
facilities for storing and retrieving persistent objects, should
remove this problem.
--
-- Bertrand Meyer
bertrand@eiffel.com