Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!pyrltd!tetrauk!rick
From: rick@tetrauk.UUCP (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: Suggestion for use of Void
Message-ID: <1045@tetrauk.UUCP>
Date: 5 Dec 90 11:02:52 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP>
Reply-To: rick@tetrauk.UUCP (Rick Jones)
Organization: Tetra Ltd., Maidenhead, UK
Lines: 53

>In article <1037@tetrauk.UUCP> I wrote:
>>
>>	a.Create (params)		a := Create A_CLASS (params)

In article <4106@tantalum.UUCP> tom@ozmium.UUCP (Tom H. Meyer) writes:
>
>I dislike this on the grounds that it would *require* that 'Create' be a
>keyword. I hope to see the day when classes can have more than one
>creation routine and this seems to disallow it.

Of course Create currently IS a keyword in effect.  The idea of multiple
creates is interesting, but if you needed them, would they not be
differentiated by their parameters?  This raises the totally separate subject
of routines overloaded on signature, something which Eiffel does not support at
all and which I've had occasion to wish for.

If this were to be added, the big question as I see it is:  should the binding
of routine selection be static or dynamic?  Eiffel's general approach is that
everything is dynamic, but my guess is that dynamic binding of routine
selection would be an horrendous overhead.  However, static binding would
probably adequately solve all the practical needs for such a facility.  This is
not something I've tried to examine in depth - perhaps it could be a topic for
a NICE technical commitee?

Going back to Creation (in the non-biblical sense), a technique I have used a
few times when object creation is non-trivial is to have an "object generator"
class.  This class offers one or more functions which return newly created
objects.  This allows different routines to create objects of the same type,
and can invisibly create descendant objects of the type actually declared.  In
this sort of circumstance, there only needs to be one generator object in the
whole system, and so it can be provided as a once function in a "definitions"
class (this is an actual use of the "global object" concept I posted recently).
I suspect this ends up being similar to Objective-C's "factory objects";
that's just a guess as I haven't actually used Objective-C.

On your topic of differentiating generic objects, I can't add much to the
discussion with Bob Weiner.  I will say that in my work the cleanest solution
has often only come after several iterations and re-thinks, and in several
cases what I've ended up doing is a lot different from what I expected to do
when I started.  Much lateral thinking is called for to get it right.

However, I think perhaps I agree with the sentiment that OO is not the optimal
paradigm for expression parsing - or else nobody's worked out the best way to
do it yet!  It's not my area of expertise so I shall refrain from commenting
further.

Keep posting!

-- 
Rick Jones
Tetra Ltd.  Maidenhead, 	Was it something important?  Maybe not
Berks, UK			What was it you wanted?  Tell me again I forgot
rick@tetrauk.uucp					-- Bob Dylan


Brought to you by Super Global Mega Corp .com