Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!uunet!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Initialising data structures
Message-ID: <931@tetrauk.UUCP>
Date: 29 Oct 90 12:28:52 GMT
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 123

Something I am finding rather cumbersome in Eiffel code is creating initialised
complex objects.  I am interested in other opinions on this problem;  please
bear with the following while I explain what I mean ...

As an example, I need to create an ARRAY of STRINGS where the
strings themselves are literal values  The code goes something like:

	...
	local
		string_list: ARRAY[STRING] ;
	do
		string_list.Create (1,5) ;
		string_list.put (1, "first") ;
		string_list.put (2, "second") ;
		string_list.put (3, "third") ;
		string_list.put (4, "fourth") ;
		string_list.put (5, "fifth") ;

		object.routine (string_list) ;
	...

The ultimate purpose is simply to invoke "routine" on "object" with some
arbitrary number of strings.

If the array contains not strings but other objects it gets even more clumsy,
since each item has to be created individually, e.g:

	...
	local
		thing_list: ARRAY[THING] ;
		thing: THING ;
	do
		thing_list.Create (1,5) ;
		thing.Create ("first") ; thing_list.put (1, thing) ;
		thing.Create ("second") ; thing_list.put (2, thing) ;
		thing.Create ("third") ; thing_list.put (3, thing) ;
		thing.Create ("fourth") ; thing_list.put (4, thing) ;
		thing.Create ("fifth") ; thing_list.put (5, thing) ;

		object.routine (thing_list) ;
	...

Some of my classes, especially inherited ones, end up containing little more
than the sort of code above.  The deferred classes do all the work, the
implemented classes are differentiated by the lists of objects they define to
be operated on (this is as succinct a precis as I can manage without going into
long boring details of the design).

Due to the repetitive nature of this sort of stuff, I have in fact written some
shell-scripts to generate chunks of Eiffel code (ouch!).  Given a skeleton, any
required version of the above block of code can be generated simply by knowing
how many strings there are and their names;  i.e. in the above example, all I
really need to know is the 5 strings "first", "second", "third", "fourth", &
"fifth".

There seems to be something at odds here with the notion of powerful code
re-use.  I am having to duplicate lumps of virtually the same code simply to do
things in an object-oriented way, a concept which is supposed to avoid the need
for duplicating code!

In C (I will refrain from ++ :-), static initialised structures can easily be
declared, e.g:

char *names[] = {"first", "second", "third", "fourth", "fifth", 0};

but since Eiffel has no notion of static data, it seems difficult to incoporate
this sort of declaration into the language structure.


I have heard some mention of syntactic extensions to Eiffel for version 3 which
would affect Create routines, and also an idea for variable argument lists.
Either of these could solve this sort of problem if done in the right way.
E.g. the first example could simply become:

	object.routine ("first", "second", "third", "fourth", "fifth") ;

(Obviously "object.routine" would need recoding - I am not suggesting that such
a variable list should be interchangeable with an array)

Various possibilities suggest themselves for the second example:

a.	THING_LIST could be a class which inherits from ARRAY[THING], and whose
	Create routine takes variable arguments -

	...
	local
		thing_list: THING_LIST ;
	do
		thing_list.Create ("first", "second", "third", "fourth", "fifth") ;
		object.routine (thing_list) ;
	...

	One essential requirement for this solution is that the called routine
	must be able to find the actual number of arguments BEFORE traversing
	them in order to create the array with the proper size.

b.	If the notion of a "new" operator applied to a class-name is supported,
	we could have something like:

	object.routine (new THING_LIST ("first"),
			new THING_LIST ("second"),
			new THING_LIST ("third"),
			new THING_LIST ("fourth"),
			new THING_LIST ("fifth")) ;

	I make no claims as to the viability of the syntax, just a suggestion
	of semantics.


I would be interested to know:

a.	Have any other Eiffel users encountered this sort of problem?

b.	Has anyone got any more elegant techniques using the current language?

c.	Do ISE (or should it now be NICE?) have any long-term plans for the
	language which would offer an improvement - either similar to the ideas
	above or otherwise?

-- 
Rick Jones
Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp	Absence of .signature is not .signature of absence