NICE-ESG-Libs Digest Tue, 15 Aug 95 Volume 1 : Issue 283
Today's Topics:
NICE-ESG-Libs Digest V1 #278
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, 15 Aug 1995 12:10:08 -0400
From: jcm@mstr.hgc.edu
Subject: NICE-ESG-Libs Digest V1 #278
To: NICE-ESG-Libs@atlanta.twr.com
Dear Lib members
Quite some time ago, Roger Browne kindly posted some comments on
my ARRAY proposal. Some time ago I sent a response to Christine
which apparently got lost in the shuffle. To facilitate communication
Christine has graciously permitted me to post directly to the Committee
on this issue. So here goes.
----- Begin Included Message -----
Roger, thanks for the feedback. I appreciate it.
> From root@atlanta.twr.com Thu Jul 6 19:16:08 1995
> Reply-To: NICE-ESG-Libs@atlanta.twr.com
> Subject: NICE-ESG-Libs Digest V1 #278
> To: NICE-ESG-Libs-digest@atlanta.twr.com
> Content-Length: 3975
> X-Lines: 109
>
>
> NICE-ESG-Libs Digest Thu, 6 Jul 95 Volume 1 : Issue 278
>
> Today's Topics:
> Absence
> Jim's ARRAY class
>
[..]
>
> Date: Thu, 06 Jul 1995 21:45:11 GMT
> >From: Roger Browne
> 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.
Any way the Committee wants to proceed is fine with me. I would like to point
out that the change Roger alludes to below is the _only_ change (I think) that
I suggested that would affect existing implementation code. For the most
part the role that I'm trying to play is to help the committee make the best
use of pre/postconditions to clearly specify what the committee has _already
decided_ the features of ARRAY should do. So in this sense the vast majority of
my suggestions are really clarifications of, rather than changes in, ELKS '95.
Conversely, I expect that having clear specifications of the features as
they are now should help foster discussions along the lines of, "Is this
what we really want?"
>
> 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
Roger made some very good arguments for empty arrays which I've elided.
Let me put forth three specific possibilities and let the Committee decide.
1) The current version.
make (min_index, max_index: INTEGER)
-- Allocate array; set index interval to
-- minindex .. maxindex; set all values to default.
-- (Make array empty if minindex > maxindex.)
ensure
no_items: min_index > max_index implies (lower = 0 and upper = -1)
lower_initialized : min_index <= max_index implies lower = min_index
upper_initialized: min_index <= max_index implies upper = max_index
items_initialized: -- for_all i, lower..upper (item(i) /= Void implies item(i) = item(i).default)
2. My proposed version (abbreviated above)
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
ensure
lower_initialized : lower = min_index
upper_initialized: upper = max_index
items_initialized: -- for_all i, lower..upper (item(i) /= Void implies item(i) = item(i).default)
3. A version that allows empty arrays, but with a bit more control than
(1), inspired by Roger's comments
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 + 1
ensure
lower_initialized : lower = min_index
upper_initialized: upper = max_index
items_initialized: -- for_all i, lower..upper (item(i) /= Void implies item(i) = item(i).default)
My current favorite is (3) as Roger has convinced me, but of course that's
for the committee to decide. If (3) is adopted then two invariant
clauses from my earlier proposal, postive_count and valid_bounds, would
have to change.
nonnegative_count: count >= 0
valid_bounds: upper + 1 >= lower
[...]
>
> 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
I have no comment here. Mostly I'd like to help the Committee rigorously
specify whatever the group decides it wants. I'll occasionally suggest
changes to features, as I did with 'make' above, but I expect that to be
the exception to the rule.
[...]
>
> Regards,
> Roger
Thanks again for the feedback and I hope this helps,
-- Jim
[...]
----- End Included Message -----
 |
