 |
 |
 |
|
|
|||
NICE Language Committee: formals.creation
From tynor@atlanta.twr.com Mon Jan 31 09:32:30 1994 Date: Sat, 29 Jan 94 19:29:53 EST To: bertrand@eiffel.com Subject: Creation of formals Content-Length: 973 Status: RO X-Lines: 23 Greetings, Suppiah Asokan's recent question on comp.lang.eiffel about VGCC(1) has got me to thinking about the issue of creating objects of formal generic type again. We've had similar requests from other users and had convinced ourselves that there were no implementation-related constraints that would prevent us from implementing creation of formal generic types. However, I've just reread the last 2 paragraphs on pg. 292 and I see that you explicitly deal with this restriction and explain that the limitation is due to an implementation-based constraint. I'm specifically puzzled by your mention of the need for extra fields in _instances_ of generic classes. I can't imagine what these fields would be used for. Can you enlighten me? Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= C++: One million lemmings can't be wrong. Steve Tynor Internet: Steve.Tynor@atlanta.twr.com Tower Technology UUCP: twratl!Steve.Tynor From bertrand@vienna.eiffel.com Mon Jan 31 18:14:58 1994 Date: Mon, 31 Jan 94 18:14:54 PST To: bertrand@eiffel.com, tynor@atlanta.twr.com Subject: Re: Creation of formals Content-Length: 121 Status: RO X-Lines: 6 Do you mean you are going to generate different code for r (and every routine) for each generic derivation of A? -- BM From tynor@atlanta.twr.com Tue Feb 1 19:32:21 1994 Date: Tue, 1 Feb 94 15:20:17 EST To: bertrand@eiffel.com (Bertrand Meyer) Subject: Re: Creation of formals References: <9402010214.AA06967@vienna.eiffel.com.noname> Content-Length: 691 Status: RO X-Lines: 18 You wrote: | Do you mean you are going to generate different code | for r (and every routine) for each generic derivation | of A? No. I think this could be implemented in the same way that one implements creation of an entity of implicit type where the entity's type is subject to redefinition. My guess is that ISE and Tower's code generation strategies are sufficiently different so that any precise explanation of how TowerEiffel would do this would be irrelevant to ISE Eiffel3. However, in Tower's case at least, the obvious (not necessarily best) implementation would be very similar to the above mentioned case and would not require any new fields in the object instance. Steve
|