On 12/03/2008, Emmanuel Stapf [ES] <
[hidden email]> wrote:
> > I meant to say that the routine contracts should be moved
> > into STRING_GENERAL, not the implementations (at least, not
> > in all cases).
> > That way, exclusive users of STRING_8 will not be affected.
>
>
> I see, that's ok then.
>
>
> > As for finding the time, I think I can probably do this (I
> > will need to get confirmation from Mark) in work time.
>
>
> This would be great indeed.
>
> Manu
Here is my initial assesment of what needs to be done. Comments are
more than welcome:
Contract for item_code moved to STRING_GENERAL; implementation uses
area, so cannot be moved.
True_constant and false_constant? Issued raised on freeelks-devel. It
seems that it is necessary
to define these as STRING_8. They may as well be moved to STRING_GENERAL.
Shared_with could be generalized, but probably not worth it.
Index_of/last_index_of cannot be moved owing to a lack of
CHARACTER_GENERAL. This means clients
of STRING_GENERAL have to use index_of_code, which is not a severe
limitiation, but the lack of
last_index_of_code is a problem - it needs adding.
Substring_index_in_bounds needs to be tackled. This means tackling
STRING_SEARCHER. Not yet assessed.
String could be moved to STRING_GENERAL with type like Current. (Any
problems with that?)
String_representation in STRING_32 is very odd. The comment is wrong,
and the test seems unlikely to
fail (it can only do so if users create descendants of STRING_32). I
wonder what its purpose is. The
version in STRING_8 looks alright, but is never used anywhere within
FreeELKS. Nor is it present in
ISE 5.7.
For substring_index and fuzzy_index, see comments to
substring_index_in_bounds. Substring_index is a very
important feature.
Occurrences cannot move owing to a lack of CHARACTER_GENERAL. This is
probably not a problem, but code_occurrences (with
a precondition of valid_code) could be added as a deferred routine,
and the implementations could simply call occurences.
Index_set apparently cannot be moved owing to a lack of
CHARACTER_GENERAL. While this is unlikely
to worry many people, the lack of item is far more serious. However it
can be coded around using is/as_string_8/32.
The use of item_code can often substitute for item.
Is_equal does not need moving (and cannot move, as it uses area). This
is not a problem, but its like Current
argument is. In particular, its use in the postcondition of
substring_index_in_bounds is a problem. But this is hardly
as big a problem as its use in client code. We need to test a STRING_8
and a STRING_32 for equality (they are equal
if they have the same count and item_code (i) = other.item_code (i)
for all valid_index (i). We could just mandate
the use of same_string instead. But in this case the postcondition of
the latter will need to be removed.
To be considered further.
Is_case_insensitive_equal needs its argument changing to a
STRING_GENERAL. Is_valid_as_string_8 needs removing from
the preconditions, and the contract should be moved to STRING_GENERAL.
The current implementation in STRING_8 can stay,
but the implementation in STRING_32 needs to change to be like
{KL_STRING_ROUTINES}.same_case_insensitive (perhaps - this
uses a legacy string algorithm, which is never necessary for
comparison. A more correct case-insensitive comparison can be achieved
by calling {ST_UNICODE_CASE_MAPPING_INTERFACE}.upper_utf8_string on
both strings, and then calling is_equal on the results, although
one would want a more efficient routine in practice - which will need
to be coded. But this may be too much for the kernel (?).
As an interim measure, we can use the algorithm of
{KL_STRING_ROUTINES}.same_case_insensitive with a note that this can
produce
false negatives (the example of ESSEN (German - to eat) with its lower
case variant (one character shorter) can be given,
along with a note that full Unicode case folding is needed to
eliminate false negatives.)
To be considered further.
Same_string needs to take a STRING_GENERAL as its argument, and the
contract moved to STRING_GENERAL.
The postcondition needs to be removed. The implementations will need
changing (they cannot use area unless
the other object is of the same type).
Infix "<" is a real problem as the argument is like Current, from
PART_COMPARABLE. actually, even the comment
is not really accurate, as lexicographic ordering is
language-dependent. This is not a minor quibble, but a very important
point.
While it is true that character strings can be ordered, and therefore
it looks legitiimate for STRING_GENERAL to inherit from
COMPARABLE, in practice the total ordering needs to be defined by the
application. This is why Gobo has the class ST_COLLATOR
which is intended to have descendants, in particular, but not
exclusively, a future descendant ST_UCA_COLLATOR,
which will implement the Unicode Collation Algorithm. Currently
ST_COLLATOR inherits from KL_COMPARATOR [STRING_8]. This will
need to change to KL_COMPARATOR [STRING_GENERAL].
My suggested "solution" is to retain infix "<" for legacy
applications, unchanged except for the comment. For that, I propose:
-- Is `Current' lexicographically earlier than `other' according to
the Unicode Codepoint collation?
Has_substring should take a STRING_GENERAL. Issues are those for
substring_index.
Starts_with/ends_with should take STRING_GENERAL as the argument, and
the contract should be moved to STRING_GENERAL.
The implementations will need to check for the type of the argument,
and if not the same, call the definition postcondition
routine, otherwise continung as now.
The implementation of valid_code is incorrect in STRING_32. The
correct implementation can be found in
{UC_UNICODE_ROUTINES}.valid_non_surrogate_code (after changing types
from INTEGER_32 to NATURAL_32).
Is_number sequence can be moved to STRING_GENERAL, along with
is_valid_integer_or_natural (both have identical
implementations and contracts).
Is_real can be moved to STRING_GENERAL. Is_double can have its
contract moved to STRING_GENERAL.
Is_boolean can have its contract moved to STRING_GENERAL
(and altered in accordance with the proposed changes for
true_constant/false_constant).
Is_integer_8/etc. and is_natural_8/etc. can all be moved to
STRING_GENERAL en masse.
Set could have its contract moved to STRING_GENERAL, and the type of
its first argument changed to
STRING_GENERAL. This would require a virtual precondition on the
contents of the substring being suitable
(i.e. is_valid_as_string_8 if Current is STRING_8), and the
implementations would need to test the type of the argument.
This does not seem worth it, as I think it is not an important feature
(there are no callers within Gobo, and very few within AXAR,
and these only of the STRING_8 variety in situations where the data is
known to be ASCII),
and that clients can do the necessary work themselves should they need to.
Subcopy is similar to set, but it appears to be more important judging
by its usage. Even so, I don't see any urgent
need to tackle this yet. Subcopy and set can be left to a future
review, I think. Also, there is a possible argument
that subcopy should be consistent with copy.
Replace_substring is a similar case to subcopy, and seems to be even
more widely used. But again, I see no urgent need for action.
Replace_substring_all takes this tendency even further (it is yet more
widely used). I now find it being used within Vision2
applications, but it looks like these usages are not Unicode-safe
anyway. It seems starnge that the original is required
to be valid as string 8, but not the replacement. I cannot see any
justification for this within the implementation.
Anyway, it depends upon replace_substring, so action (other than
removing the unnecessary precondition, if it is unnecessary)
can wait.
Replace_blank and fill_blank can have their contracts moved to
STRING_GENERAL (I'm not sure about their all_blank
postconditions - for replace_blank, this can be rewritten as per
fill_blank, or use code_occurences).
An equivalent routine for fill_with, fill_with_code, could be declared
in STRING_GENERAL with the precondition of valid_code.
The implementations might simply call fill_with. Likewise a
fill_character_code can be written to use fill_character.
I see no reason for the introduction of the obsolete routines
head/tail into STRING_32 - these should just be removed.
Likewise replace_character.
Keep_head can be moved into STRING_GENERAL. Keep_tail can have its
contract moved to STRING_GENERAL.
Left_adjust can have its unnecessary precondition removed (this
requires removing the unnecessary precondition from
{CHARACTER_32_REF}.is_space and altering that implementation
accordingly), and the contract can then be moved to STRING_GENERAL.
Ditto right_adjust.
Why is there no prepend in STRING_GENERAL? I cannot see why the same
approach is not taken as for append.
Prepend_boolean/prepend_double/prepend_integer/prepend_real can all be
declared deferred in STRING_GENERAL. And suitable
postconditions could be added to declare the semantics, if that were
ever done for {BOOLEAN_REF etc.}.out.
An equivalent for prepend_character, prepend_character_code, can be
declared in STRING_GENERAL with a precondition of valid_code,
and the implementations can just call prepend_character, or call put_code.
Infix "+" could have its contract declared in STRING_GENERAL, and its
argument declared as a STRING_GENERAL - it would require an
additional precondition:
compatible_strings: is_string_8 implies s.is_valid_as_string_8
The implementations can use append_string_general.
Append_integer can be declared in STRING_GENERAL. A post-condition can
be added that the count has increased.
The implementations are identical, but make use of area, so they must
stay separate.
Ditto for sized variants and append_natural and sized variants and
append_real and append_double and append_boolean
(although the proposed postcondition for these last three is
techincally unprovable as as .out does not have a
corresponding postcondition. I think an ensure then should be added to
these descendants of {ANY}.out to make this safe.).
I see no reason for the presence of the obsolete routine
{STRING_32}.insert. It should just be removed.
The contract for insert_string can be added to STRING_GENERAL,
changing the first argument to STRING_GENERAL, and adding the
precondition:
compatible_strings: is_string_8 implies s.is_valid_as_string_8
The implementations will have to check for the correct type, and if
not, use a slower algorithm (inserting character-by-character from the
item_codes).
Insert_character can obviously not be declared in STRING_GENERAL, but
the contract for an equivalent (insert_code) could be (with
the constraining precondition of valid_code). The implementations
could just use insert_character.
Internal_hash_code might as well be non-deferred in STRING_GENERAL.
Then implementations can assign to it in STRING_GENERAL.
Remove_head can then just be bodily moved into STRING_GENERAL
(otherwise, just its contract should be moved). Ditto remove_tail
and clear_all.
Remove_substring should have its contract moved to STRING_GENERAL.
Prune - like other routines that accept a CHARACTER_nn, a contract for
prune_code can be added to STRING_GENERAL. Likewise
prune_code_all, prune_code_all_leading and prune_code_all_trailing.
Adapt_size should just be moved into STRING_GENERAL. Likewise grow.
It seems to me that resize should have a postcondition stating that
capacity >= newsize. Likewise grow.
As_lower.
This routine should be simply moved from STRING_32 to STRING_GENERAL.
The STRING_8 version can be thrown away, as it is the same.
It implements a legacy case conversion (the postcondition states that
the length won't change). We should add a second comment
warning of incorrect results (such as lower-casing ESSEN).
Ditto as_upper.
Left_justify should have its contract moved to STRING_GENERAL. Ditto
right_justify.
Ditto for center_justify (using the STRING_8 version of the contract).
A version of character_justify, character_code_justify, can have a
contract in STRING_GENERAL
and the implementations can just call character_justify.
To_lower/to_upper. The STRING_32 version of the contract should go
into STRING_GENERAL.
We should add a second comment warning of incorrect results (such as
lower-casing ESSEN).
To_integer/natural_8/16/32/64 (and unsized variants) should just be
moved into STRING_GENERAL.
Likewise to_real/to_double/to_boolean.
Nothing can be done about linear_representation. Fortunately, it
doesn't appear to be very widely used.
A routine, split_on_code, could be added to STRING_GENERAL. Split is
widely used, so this might be necessary.
The Gobo class, ST_SPLITTER, suffers from some of the same problems
(because of escape_character).
Mirrored is a dodgy routine in a Unicode context - at least as far as
the name goes, as some characters have
different glyphs depending upon whether they are presented ltr or rtl.
Nevertheless, this routine can simply
be moved into STRING_GENERAL, and mirror can have its contract moved
into STRING_GENERAL.
Multiply can have its contract moved into STRING_GENERAL. A
postcondition on the count seems sensible.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
