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