NICE-ESG-Libs Digest        Tue, 13 Jun 95       Volume 1 : Issue 261 

Today's Topics:
                     NICE-ESG-Libs Digest V1 #260


NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Tue, 13 Jun 95 18:06:03 EDT From: tynor (Steve Tynor) Subject: NICE-ESG-Libs Digest V1 #260 To: NICE-ESG-Libs@atlanta.twr.com Bertrand wrote: | In fact the assumption was that the _REF classes do effect the | features mentioned by Steve, but do not export them, so the short | forms are legal. (Such forms are not meant to be ``legal Eiffel'', | just legal short forms.) | | Although perhaps debatable, this decision makes sense: the _REF | classes are there to provide a place in the type system for the basic | classes, and to allow expanded-reference transformations, but they are | not meant (in my view at least) to be used by themselves. That's a rather odd restriction. In our implementation, the _REF classes have always kept the features exported exactly as imported. And in fact, I've seen user code which instantiates INTEGER_REF for the purposes of keeping a "shared" integer. I've just checked my copy of Eiffel/S 1.3 and an old copy of the ISE kernel and note that neither of them reexport to {NONE}. Why would we want to change this now? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= A moose once bit my sister. Steve Tynor Internet: Steve.Tynor@atlanta.twr.com Tower Technology UUCP: twratl!Steve.Tynor WWW: http://www.cm.cf.ac.uk/Tower/