Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel
Subject: Re: Interesting problems to try in Eiffel
Message-ID: <2645@tukki.jyu.fi>
Date: 9 Jan 90 08:11:16 GMT
References: <1721@novavax.UUCP>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 68

In article <1721@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes:
>(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.

> [several other examples ...]

>* 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.
> [...]

Fortran's NAMELIST input is probably among your favourites ...
There are times when one would like to have this kind
of facilities; I think there have been such questions recently
at least in the Pascal newsgroup. However, it would not be _simple_
to offer such facilities in any compiled language - variable names
in them are generally only compile-time entities; preserving them
at run time would greatly impede efficiency.

More importantly, exposing attribute names to users at run time
would be in glaring contradiction with some of Eiffel's most important
principles: abstraction and encapsulation. Read more carefully about
the open-closed principle and note that the 'closed' part is just
as important as the 'open' part. (I confess that it isn't too easy
to understand what exactly Meyer wants the "open-closed principle"
to imply.)

Concerning your specific example:
If a programme needs a large number of initialisation parameters,
a quick-and-dirty solution to input them will probably not be good
anyway, especially considering later modifications.
Very likely one would need to make several feasibility checks before
accepting the set of initial parameters in the first place.
An object-oriented way to solve the problem could be to design some
classes and operations for handling a more general case,
then specialise to the actual situation.

I would bet that self-modifying programmes draw more interest in the 50's
than they will in the 90's (I think object-orientation offers in a
disciplined way much of the flexibility for which self-modification
would be needed otherwise). At least, they belong more to the domain of
"exploratory programming" than that of "software engineering".
The target of Eiffel is the latter.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland