NICE-ESG-Libs Digest Thu, 25 May 95 Volume 1 : Issue 226
Today's Topics:
ARRAY and STRING suggestions
Paul's manifesto
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, 25 May 1995 14:05:57 +0100 (BST)
From: S M Fisher <S.M.Fisher@letterbox.rl.ac.uk>
Subject: ARRAY and STRING suggestions
To: NICE Library Committee
ARRAY
-----
I do not think anyone will be able to remember the difference between
features `entry' and `item' and between `put' and `enter'.
I suggest that we should have instead:
`item' and `frozen_item'
`put' and `frozen_put'
The last line of the comment for `resize' cannot be true unless the new
interval includes the old one.
I would like to see two new features
clear
-- clear the array (set all items to default values)
ensure
cleared : cleared
cleared : BOOLEAN
-- do all items have default values?
STRING
------
is too big, so we should eliminate a few things if possible.
Rename `wipe_out' to `clear' and `empty' to `cleared'
`remake(n)' is equivalent to `clear; resize(n)' and is of limited use. I
would abandon it. It is also odd because it is not a creation feature
though it contains the string `make'.
I do not see why we have `share' and `shared with' it a a complication we
can well do without. Why is it there?
item_code(i) could be replaced by item(i).code so I suggest this is also
dropped
For all the comparison features the collation sequence should be
specified.
All of the append_type features should be dropped in favour of
append_string which should be renamed as append because:
`append_boolean(b)' is equivalent to `append(b.out)'
The comment on `append_string' (which I would prefer to be append) is
ambiguous. Is it a precondition that s != void ? If not the
postcondition is wrong. I would favour the precondition.
`fill_blank' should be replaced by the more useful
make_and_fill(n: INTEGER, c : CHARACTER) which would create a string with
n copies of the character c. This could be used for generating a series
of blanks, `-' or `=' signs for example.
left_adjust and right_adjust refer to white space. Does this include tabs,
CR and LF as normal? I suggest it should. The action of right_adjust is
not what one would expect from the name. So I suggest calling it
right_trim and so we should have left_trim to match.
I would drop prepend because prepend(str) is equivalent to insert(str,1).
Also `prepend' is not a word in English, it is only computer-speak.
`replace_substring' should have the same arguments as `insert' and should
be simply called `replace'. So insert("fred",1) inserts fred at the
beginning and replace("bill",1) would then overwrite the first four
characters with "bill"
I do not think I would find `set' too useful. But I could easily be
persuaded otherwise.
Why the interest in mirrors? Though this often occurs in books on
programming, I can think of no practical use for reversing a sequence of
letters.
Of the other conversion routines I would prefer to_lower and to_upper to
return strings rather than changing the current string. This makes them
more like the other to_ features.
Question
--------
Finally I have a question which affects the need for some of these functions.
What is the effect of s := "abc"? Is it equivalent to s := clone("abc")?
Currently they are equivalent for SiG but not for tower, which allows you
to mess up the literal. I accept that having
s := sc
s.append("junk")
...
sc : STRING is "changeable"
will modify sc, but I feel that
s := "unchangeable"
s.append("junk")
should always give: "unchangeablejunk"
i.e. that := literal string should imply a clone. The same should be true
of a manifest array. Does anybody know if the language committee have
considered this please?
Regards,
Steve Fisher
Date: Thu, 25 May 1995 10:20:27 +0100 (BST)
From: S M Fisher <S.M.Fisher@letterbox.rl.ac.uk>
Subject: Paul's manifesto
To: NICE ESG Library Committee
Hi,
As I feel that the library committee work is progressing much too slowly,
I have to vote for some change. This means that my vote will go to Paul
on June 1st.
I strongly support the change in voting rules which Paul has suggested,
though it does not address the more fundamental problem that few points
are openly discussed before the vote. Perhaps his weekly summary of the
state of play might help.
I do not like the idea that "any member who misses two consecutive votes
without good reason will be removed from the committee." I would expect
any member of a committee who shows such a lack of interest to simply
resign without being pushed. In addition, assuming that Paul's new voting
rules are accepted he or she would be harmless - which is not currently
the case.
I do not like the idea of "non-executive members" as the structure seems
unnecessarily complex. I would prefer to see the membership fees for
individual membership of NICE just cover costs so that capable individuals
are not excluded. As I have never received any mailings from NICE nor any
indication that more money has been spent as a result of my joining NICE,
I guess that costs cannot be more than a dollar or two.
I hope that under the next chairmanship we will have a clear plan and
timescale for getting the first version of PELKS to an accepatable form,
and that a means will be found to move a lot faster.
Steve Fisher
 |
