Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!unmvax!bbx!tantalum!tom
From: tom@eds.com (Tom H. Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Suggestion for use of Void
Message-ID: <4212@tantalum.UUCP>
Date: 6 Dec 90 19:55:01 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP> <1045@tetrauk.UUCP>
Sender: usenet@tantalum.UUCP
Reply-To: tom@ozmium.UUCP (Tom H. Meyer)
Organization: EDS Research
Lines: 58

In article <1045@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>>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?  

Not necessarily. It's easy for me to envision two different creation routines
that had identical interfaces. There's also a question of implicit information
here. I usually oppose implicit information. In this case we have, "all
creation routines are named 'Create' but you tell them apart by their
arguments." I'd rather see all the creation routines given complete liberty
with their name and, perhaps, add some additional keyword to identify this
function to the compiler as a (additional) creation routine. Perhaps

	other_create (...) is
		create_proceedure
		require
			...
		do
			...
		end;

>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.

Sure. That's actually a better solution than what I had in mind. Since it's
fairly straight forward to get the functionality, perhaps it's better to not
clutter up the language with the additional features.

>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.

I certainly can see that. OOP is rather different is style and feel to the
other paradigms and it takes getting used to. There is a raging debate right
now about how to do object oriented design, capture the objects, etc.

tom meyer, EDS Research               | If I don't see you in the future
...uunet!tantalum!tom                 | I'll see you in the pasture


Brought to you by Super Global Mega Corp .com