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, 06 Jul 1995 22:15:35 GMT From: Roger Browne <rogerb@eiffel.demon.co.uk> Subject: Absence To: NICE-ESG-Libs@atlanta.twr.com I will be away from email contact from 8th to 14th July inclusive. -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-1772-687525
Date: Thu, 06 Jul 1995 21:45:11 GMT From: Roger Browne <rogerb@eiffel.demon.co.uk> Subject: Jim's ARRAY class To: NICE-ESG-Libs@atlanta.twr.com Library Committee Members, Jim McKim posted an ARRAY class for discussion, and wrote: > ...I'm looking > forward to discussing these specifications with you and, of course, hope that > one or more of you will champion this work to be part of Vintage '96. I think it's a good thing for all Library issues to be discussed as widely as possible within the Libraries Committee. However I hope that when the time comes for specific proposals for Vintage '96 that these will be formulated as small incremental changes to the '95 document. Jim, I'm a little short of time right now to respond to all your suggestions in full, so I will restrict this note to just two comments. > Class ARRAY > > creation > > make (min_index, max_index: INTEGER) > -- Allocate array; set index interval to > -- min_index .. max_index; set all values to default. > require > valid_indices: min_index <= max_index > ... > invariant > positive_count: count >= 1 I am interested to know why you don't want to allow empty arrays. In many applications the number of objects to be stored in an array is not known in advance. For example, there may be one entry in an array for each transaction with a certain date. In such cases, zero is often a valid number of entries, and it seems a pity to make a special case of it. Often a loop is used to examine all the elements of an array in turn. If empty arrays are allowed, we automatically get sensible behaviour in such a case because the loop body is never executed. The '95 vintage places no constraint upon the values of 'minindex' and 'maxindex'. You could even strengthen this to: valid indices: min_index <= max_index + 1 which would still allow empty arrays to be created (when min_index = max_index + 1). My second comment relates to features which are also present in the '95 vintage. I would be interested to know why it was felt desirable to make 'item' and infix "@" frozen. I can only presume that it is to make it easier for the compiler to optimize array-handling code. In that case, do we need the non-frozen version in the kernel class at all? Surely it can be introduced in some child class if and when it is needed? I fear that we are making Eiffel harder to learn and more error-prone to use by providing multiple similar but subtly-different features. Please excuse me if these issues have already been discussed during my absence from NICE (in which case a pointer to such discussion would be appreciated). Regards, Roger -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-1772-687525
