NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/object/3015

Internet Message Format | 1992-07-27 | 3.5 KB

Xref: sparky comp.object:3015 comp.lang.eiffel:986
Path: sparky!uunet!mcsun!corton!irisa!irisa.fr!jezequel
From: [e-mail] (Jean-Marc Jezequel)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: How to design a data structure library.
Message-ID: <[e-mail]>
Date: 27 Jul 92 12:33:45 GMT
References: <1820@snap>
Sender: [e-mail]
Organization: Irisa, Rennes(FR)
Lines: 67

In article <1820@snap>, [e-mail]-mrc (Paul Johnson) writes:

|> Cursors
|> -------
    This is a complicated issue, and I think more research should be made before
having to choose on one of the proposed issues, most notably at the semantic level.
Howver, I would like to make 2 remarrks:
    1) cursors (or iterators) should be independant of the underlying data structure
aggregate. Here I find the SmallTalk concept of Collection usefull, with array and list
and set and others inheriting from it (with possible intermediate classes, like
OrderedCollection). Iterators should be defined on Collections, and possibly redefined in
subclasses for efficiency issues.
    2) User interface of the cursor notion should be very simple because otherwise
nobody will use it, as writing an had hoc loop is so deeply built-in the mind of the
average programmeur.
|>
|> RISC vs CISC
|> ------------
    I am for CISC, as selecting is always easier than building.
|>
|> Functional vs Procedural
|> ------------------------
|> Does it make sense to implement both kinds of operations in a class,
|> so that the programmer can pick the appropriate one?

YES, absolutely. I think it should be the rule.
Furthermore, it is not very hard to implement.
For instance, your set example could be programmed like this:

UnionWith (other:like current) is
  --perform the operation Current := Current Union other
  --in an efficient way, by modifying directly Current
  -- (the name of this feature in Eiffel 2.3 is "merge")
end;

infix "+" (other:like current):like current is
  do Result.clone(Current); Result.UnionWith(other); end;

I can't see any disavantage of this approach (even for efficiency reasons, as an Eiffel
compiler could do the inline expansion of infix "+" --I think ISE 2.3 does it already).
Pros are:
- algorithm complexity  should be the same than a direct solution for infix "+"
- this works for a lot of data structures (think of matrix computations for example)
- the clone trick allows one the deal with deferred and generaic classes, wheras you
couldn't create instances of such classes, as needed with a direct solution (Result.Create
is rejected by the compiler in such cases).
-I am not sure, but in Eiffel 3 the feature UnionWith could have a prefix syntax (a la C):
 infix "|+=" (other:like current) is...
 (Is it true for procedure features? I can't see why it shouldn't, but I did'nt saw it
explicitely in ETL)

|> Documentation
|> -------------
Why not using a relationnal database?
Or at least the Unix "man" facility with one man page (in a special section) for
each class, an another one for each Cluster, all of it with a good use of the "keywords"
field to work with: man -k
This should be simple (the tool is there) and nearly automatic: the man page could be
extracted from the text of the class, as for tools like short and flat.

Sure it would be the role of NICE to propose a "standard" solution at that level.


--
+----------------------------------------------------------------------------+
| Jean-Marc Jezequel, IRISA/CNRS, 35042 RENNES (FRANCE) // [e-mail] |
+----------------------------------------------------------------------------+