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: Thu, 21 Dec 1995 12:30:51 +0000 From: Roger Browne <roger@eiffel.demon.co.uk> Subject: NICE-ESG-Libs Digest V1 #323 To: NICE-ESG-Libs@atlanta.twr.com Fellow committee members, In NICE-ESG-Libs Digest Issue 323 Steve Tynor wrote: > Consider the following comment in the proposed RB-2 version of ARRAY: > > | make_from_array (a: ARRAY [G]) > | -- Initialize from the values of 'a'. > | -- Useful in particular when 'a' is a manifest array. > | -- Note: representation may be shared; to avoid sharing, > | -- use as "make_from_array(clone( a ))" > ... > I don't think it's a good idea to allow sharing of representation for > this standard feature... I agree with the reasons that Steve gives for not wanting sharing of representation. I also believe that sharing of representation gives rise to an undesirable degradation in readability of Eiffel code (based on my interpretation of the comments "useful...when 'a' is a manifest array" and "representation may be shared"). To be specific, I believe the following code fragment should always result in the the 'yes' branch being executed: a: ARRAY[BOOLEAN] ... !!a.make_from_array(<< true >>) if a @ 1 then -- 'yes' branch else -- 'no' branch end However, with sharing of representation the 'no' branch could be executed under some circumstances, for example: a: ARRAY[BOOLEAN] i: INTEGER ... from i := 1 until i > 2 loop !!a.make_from_array(<< true >>) if a @ 1 then -- 'yes' branch else -- 'no' branch end a.put(false, 1) i := i + 1 end Shared implementations can lead to very subtle bugs, and seem to offer little if any benefit to the Eiffel programmer. > If sharing is necessary to ISE, I propose that the standard contain only > the non-sharing version... I agree with this proposal. > ...(I don't care what it is called: if it improves > backwards compatibility for ISE to call the shating version > `make_from_array', then so be it: lets call the standard feature > something else)... The convenient name 'adapt' is possibly still available for this purpose. > ...If two implementations provide different semantics, they > should be made available under different names. Yes. Regards, Roger -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-1772-687525
