Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!brunix!doorknob!rsw
From: rsw@cs.brown.EDU (Bob Weiner)
Newsgroups: comp.lang.eiffel
Subject: Re: Suggestion for use of Void
Message-ID: <RSW.90Dec4075159@tahiti.cs.brown.EDU>
Date: 4 Dec 90 12:51:59 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP>
Sender: news@brunix.UUCP
Organization: Brown U.
Lines: 60
In-reply-to: tom@eds.com's message of 3 Dec 90 22:19:21 GMT

In article <4106@tantalum.UUCP> tom@eds.com (Tom H. Meyer) writes:
>
> Since you asked for some net traffic and we're talking about programming,
> I would like feed back on how some others out there would do the following:
> 
> Suppose I have some class which which has a list of generic objects and
> my application needs to examine every item on the list and perform 
> different actions based on the actual type of the items on the list.
> 
> My solution is a sequence of reverse assignment attempts to,
> first, determine the actual type of the object, and, second, have a
> local object of the correct type to access the specific object's features.
> 
> I've heard that this is poor style but I've never been able to see a
> better way to do it. Supposedly, there is some way of designing the classes
> so that this isn't necessary. Can anyone give me an example?
> 

The key question is whether you know at class design time whether or not
objects of the class type will be used on the list.  Even if you don't,
you could still define a somewhat generalized protocol (varying numbers
of parameters are still a problem) in which all of your non-generic
classes have an arbitrary 'action' procedure.  Then when you pop an
object off the list into an entity of type ANY, simply invoke
'entity.action(params)'.  Eiffel's dynamic binder will do the rest.

My guess is that your problem is more complicated than this, so you will
have to elaborate some more.  Your problem does demonstrate a weakness
of current object-oriented languages that I have recently been
investigating.  I call it the 'context conditional' problem.

Dynamic binding solved the 'typecase conditional' problem, allowing one
to work with an open ended set of types all of whose features are
properly invoked at runtime, without the need to modify completed source
code in order to add a type.

But today's widely-used OO languages have no mechanism for dynamically
binding features based upon contexts, where a context is defined as some
set of constraints on the program state at runtime.  Thus, one still
needs code of the form:

	if var1 = 10 and flag1 = true then
	     obj.action1
	elseif var1 > 10 and flag2 = false then
	     obj.action2
	...
	endif

This yields a similar problem as one had with embedded typecase
statements.  That is, every time a new constraint type is added one must
modify code possibly spread throughout a number of classes.

The solution I am working on involves multiple class protocols called
views coupled with contextually linked constraints.  Details are too
lengthy and not yet complete enough to go into here, but I wanted to
mention these ideas as possible long term solutions to the sort of
problem you are now faced with.

--
Bob Weiner				   rsw@cs.brown.edu


Brought to you by Super Global Mega Corp .com