Re: [gobo-eiffel-develop] Usage of INTEGER_64

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> and is_decimal_digits is certainly a better name than is_integer,
> because the latter suggests (to me) a necessary and sufficient
> condition for converting to INTEGER, which it isn't.

Class KL_STRING_ROUTINES was initially written to have a
compiler independent version of features that are in class
STRING. At the time of writing, feature `is_integer' was
what was available in some compilers but not in others.
ELKS fixed the specification of `is_integer' and now it
is clear that we should rename this feature in KL_STRING_ROUTINE
and provide another implementation (following ELKS spec)
for `is_integer'. In fact when `is_integer' was introduced
in KL_STRING_ROUTINES it was to be used as precondition
of STRING.to_integer, so this modification will just fix
a potential bug (old versions of compilers were not dealing
with the fact that the value had to fit into an INTEGER).
For consistency with `is_hexadecimal' I would name the
old feature `is_decimal' (rather than `is_decimal_digits').

> In any case, an is_integer_64 routine is needed as a pre-condition for
> to_integer_64.
> 
> And we first need to decide what it should stand for.
> 
> The most intuitive meaning is that is_integer_64 implies that the
> contents of the string concerned matches the lexical pattern of an
> Eiffel INTEGER_64 literal. In which case my initial implementation of
> to_integer_64 is insufficient.

I don't think that KL_STRING_ROUTINES is there to reinvent
the wheel (we have the string library for that). In KL_STRING_ROUTINES
we should just make routines compiler independent. So we should
just look at what is already provided in Eiffel compilers supporting
this feature, and what is in ELKS for `is_integer' to see how
we can apply it to `is_integer_64'. As far as I can see, none
of those accepts underscores (unlike Eiffel INTEGER_64 literals).

> But then we have an inconsistent story with is_integer. Can we rename
> this to is_decimal_digits? This will break existing clients, so we can
> only do that if the next Gobo release is numbered 4.0 (there is a
> precedent in that the upgrade from 2.0 to 3.0 broke some existing clients).

Do we need to break code now, or go to the "obsolete" stage
before?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com