Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!weiner
From: weiner@novavax.UUCP (Bob Weiner)
Newsgroups: comp.lang.eiffel
Subject: Interesting problems to try in Eiffel
Message-ID: <1721@novavax.UUCP>
Date: 6 Jan 90 01:16:10 GMT
Organization: Motorola Inc.
Lines: 94

(I assume you're using Eiffel 2.2.)

I should warn readers that ISE's Eiffel has much to recommend it and so
far I'm still apt to promote its use.  But in fairness I present here a
number of example tasks that should be simple but aren't.  Thus, they
either reflect my lack of Eiffel expertness or they reflect weaknesses
in the environment.

* Build a COMPLEX_NUM class.  This is one of the most basic classes needed
for any sort of scientific programming yet missing from the ISE provided
Eiffel libraries.  Naturally you'll want it to be an expanded type just
like an INTEGER.  But you'll find there is no way to define an expanded
class but only expanded instances.  Thus your code will be littered with
declarations of the type 'c: expanded COMPLEX_NUM'.  Very, very
unnerving for such a simple idea.

Though ISE promotes the language as 'the' general programming solution,
judging from the poor organization of their almost non-existent math
libraries, they have done little if any programming in Eiffel in this
area.  (To my mind, there is no reason that math/science programs need
object-orientation any less than any other domain.  Possibly they need
them more judging from the poor Fortran code that floats throughout the
universe.)

* Add an INTEGER to a REAL.  The compiler will tell you something akin
to INTEGER is not a descendent of REAL.  Conceptually, it should be a
specialization of and thus should inherit but the more significant
matter is that this is a simple thing that programmers often do everyday,
yet it does not work as expected.

* Create an SDF (system build configuration file) in directory A and a
class in directory B.  This is often useful as one tries to categorize
classes in the same system below different directories.  Now try to
compile the class from directory B which is where you are likely to be
if you have just edited the class and want to see if it will compile.
You'll find that the compiler can't locate the SDF and so remains unhappy.
'ec' the Eiffel class compiler has no published option with which to
specify the SDF directory as does 'es', the Eiffel system builder.  Is
this the result of two different implementers not speaking to one
another in the same small company?

* Use a smart editor to parse ISE's Eiffel compiler error
messages in order to displaying the offending class line.  It can be
done but is made very difficult by the fact that error messages do not
contain full pathnames but only class names.

* Regression test an Eiffel system using any ISE supplied testing
facilities.  ISE has indicated that their current tools, after a couple
of years of development, do not support this.  How can one talk about
adequate solutions to programming-in-the-large without designing in
regression test support?

* Create a large class library without creating any names that conflict
with ISE library class names.  My belief is that a class definition
which represents a data type to be used in programs should be named
clearly enough to indicate its true nature.  Classes that implement
obviously incomplete abstractions should not take the name of the
abstraction.  Part of the point behind OO is to represent abstractions
in a way that will appear natural to people.  Now look at these ISE
class names and guess what they do: BASIC, CELL, CHAIN, COMMAND,
SCREENMAN, INTERNAL.

My best guess would be:  A grammar class for the BASIC programming
language, a biological or criminal containment unit, a linked set of
units that holds something else down, a guy who fixes screen doors, and
of course an ISE internal class for functions that just would not fit
anywhere else.  All of these guesses are naturally entirely wrong.  Not
much energy is required to come up with better names either.  Naming
conflicts are avoidable if decent naming conventions are used.

* Cast the value of a STRING into an entity name and then assign to it.
This is fairly common in Lisp.  This may break the type system but is
extraodinarily useful in everyday practice.  (How can one justify
elegance in the face of impracticality anyway?)  Suppose one needs a
hundred separate input parameters to initialize a program.  Command line
options are thus impractical.  Instead a file with two fields per line
is created with one parameter per line.  The first is the parameter name
which is the same as a program attribute name and the second is the
parameter value.  The problem is how to assign the value to the actual
program entity with the right name?  Without the aforementioned
capability, one is in for a very long if-then-else structure which is
both inefficient and contrary to the open-closed principles often
eloquently espoused by Dr. Meyer.  A non-mundane use of this facility
would be to create a self-modifying program; a concept that is going to
play an important role in software throughout the next decade and
beyond.

I hope this sparks some interesting messages and also some solutions.
There is way too little traffic in this group so let's here from some
readers.

-- 
Bob Weiner, Motorola, Inc.,   USENET:  ...!gatech!uflorida!novavax!weiner
(407) 364-2087