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 95 10:49:41 EST From: tynor (Steve Tynor) Subject: `Sharing' and ARRAY:make_from_array To: nice-esg-libs 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 ))" | require | a_not_void: a /= Void | ensure | lower_initialized : lower = a.lower | upper_initialized: upper = a.upper | items_initialized: -- for_all i, lower..upper (item(i) = a.item(i)) I don't think it's a good idea to allow sharing of representation for this standard feature. Our implementation does not (as I understand Eiffel/S's does not). By not specifying that, however, users concerned about portability must do an explicit `clone' just in case an implementation shares. (which can be extreemly inefficient for large arrays since the elements will be copied twice). More importantly, however, I cannot devise a reasonable implementation of "shared" arrays that works in the presense of resizing or reallocation of the representation (the `area'). Imagine that I have two arrays; one which was created with the sharable `make_from_array' with the other as the argument. I then resize one of them such that the lower bound changes. What is a reasonable representation that will cause the other array to know its `area' was resized, realloated, or elements were shifted (any or all of which may have been a side effect of changing the lower bound of the other array handle). If sharing is to be allowed, we need BIG FLASHING WARNING SIGNS (preconditions?) saying that once `make_from_array' is called, the source or result arrays must be never be resized or reallocated (and there are several features of the class that might directly or indirectly do that: `size', `accomodate', `remake', `force', etc.). I raised this issue with Bertrand some time ago, but I have no record of ever having recieved a reply. If sharing is necessary to ISE, I propose that the standard contain only the non-sharing version (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) and that ISE support a sharing version which is proprietary to its implementation. Leaving the specification for `make_from_array' open to sharing or non-sharing is of almost no use to the end-user who cannot know the precise semantics of the feature he is calling. If two implementations provide different semantics, they should be made available under different names. Steve
