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: Mon, 6 Nov 95 09:40:14 EST From: tynor (Steve Tynor) Subject: fwd: [jacob@blackbox.enmu.edu] Please forward to the ELS committee To: nice-esg-libs ------- start of forwarded message (RFC 934 encapsulation) ------- From: "Jacob Gore" <jacob@blackbox.enmu.edu> To: tynor@atlanta.twr.com Subject: Please forward to the ELS committee Date: Sun, 05 Nov 1995 18:20:32 MST Steve, I just went through the ELS classes that I use in my book, and came across a number of concerns -- some are just bugs, some are style suggestions. Could you forward these to the ELS folks? By the way, what happens to all this stuff that gets forwarded to the standards committees? Is it eventually voted on? Thanks, Jacob ARRAY 1. [Style,question] Is the "feature --Initialization" section supposed to duplicate the "creation" section? 2. [Style,linguistic] In `enter' and `put', header comment has "replace ... by ..."; it's better to use "replace ... with ...". CHARACTER 1. [Style,consistency] In postcondition of `three_way_comparison', the label "smaller:" should be "smaller_negative:" (as it is in COMPARABLE). (See also STRING.2). COMPARABLE 1. [Typo,minor] `three_way_comparison': extra ")" at the end of the header. FILE 1. [Style,consistency] A precondition of `change_name' is labelled "not_new_name_void:". Most classes in ELS would use "new_name_exists:" (though GENERAL would use "new_name_not_void:", see below). 2. [Typo,minor] `read_line', header comment: "Make result available in `laststring'" -- should say "in `last_string'" (with "_"). 3. [Humble opinion:-] `empty' should be `is_empty'. (See also STRING.13) INTEGER 1. [Typo,major] Postcondition of `//' is "result_exists: divisible(other)". Should say "result_exists: Result /= Void". GENERAL 1. [Style,consistency] In most classes, assertions "xxx /= Void" are labeled "xxx_exists:". In GENERAL, they are labeled "xxx_not_void". STD_FILES 1. [Contract,consistency] `read_word' is mentioned in the header comment of `last_string', but not defined in the contract. [I had mentioned this in a previous submission, and Steve provided additional aspects of the problem.] 2. [Style,consistency] `put_string' has no label on its precondition. "s /= Void" should be "string_exists: s /= Void". 3. [Style,consistency] Header comment of `standard_default' is the only one I noticed in ELS that starts with the words "Return ...", and "is Void" has a capital "V". I suggest rephrasing "Return the `default_output' or `output' if `default_output' is Void" as "`default_output' if not void; otherwise `output'." STRING 1. [Typo,minor] `min', `max' and `three_way_comparison' all have an extra ")" at the end of the header line. 2. [Style,consistency] In postcondition of `three_way_comparison', the label "smaller:" should be "smaller_negative" (as it is in COMPARABLE). (See also CHARACTER.1). 3. [Style,linguistic] All `append_xxx' routines have a header comment that reads "Append ... at end." The "at end" is redundant. 4. [Contract,bug] The header comment of `append_string(s)' says `s' is ignored if void. The postcondition new_count: count = old count + s.count will crash if `s' is void. 5. [Contract,consistency] `append_string(s)' allows void `s', but `insert(s)' doesn't. 6. [Contract,consistency] Append features: append_string, append_character, append_boolean, append_integer, append_real and append_double. Insert features: insert (not insert_string) and insert_character. Another humble opinion: the column on the left below is easier to use than the column on the right: append(i.out) append_integer(i) append(b.out) append_boolean(b) append(c.out) append_character(c) append(r.out) append_real(r) append(d.out) append_double(d) append(s) append_string(s) I wasn't on the ELS list back then, so I don't know what motivated the change, but I prefer the old way. And avoids the problem of inconsistency with `insert'. 7. [Contract,consistency] The two postconditions of `wipe_out' ("count=0" and "empty") are redundant in light of the invariant ("empty=(count=0)"). 8. [Style,consistency] The parameter to `resize' should be `new_size', not `newsize'. 9. [Style,clarification] The header comment for `susbtring' should have "inclusively" at the end: "Copy of substring containing all characters at indices between `n1' and `n2' inclusively". 10. [Contract,bug] The postcondition of `fill(c)' says all characters will be blank instead of equal to `c'. Suggested postcondition: -- all_replaced: For every `i' in 1..`count', `item(i)' = `c'. 11. [Contract,consistency] ARRAY has `valid_index(i)' and uses postconditions good_key: valid_index(i) STRING has no `valid_index(i)' and uses postconditions index_small_enough: i < count index_large_enough: i > 0 12. [Contract,linguistic] While it is true that the verbs "head" and "tail" can be used as verbs, their meaning as verbs has nothing to do with what procedures `head(n)' and `tail(n)' do. If they were functions (substring(1,n) and substring(n,count)) the names would be fine. Wouldn't it be better to have `truncate_left(n)' for `tail(n+1)' and `truncate_right(n)' for `head(n-1)'? 13. [A concluding humble opinion for consistency:-] `empty' should be `is_empty' (see also FILE.3) ------- end -------
