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

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >> And I thought about the use case I have, which is parsing
    >> numbers. The tokenizer has already created tokens one of which
    >> is certified to consist entirely of decimal digits (there may
    >> be a preceding token consisting of a minus sign).  In this use
    >> case the pre-condition "is_integer" is guarenteed true.  So I
    >> tried to think about other use cases for "is_integer_64". All I
    >> could think of was parsing, and I presumed therefore that the
    >> pre-condition would always be satisfied.

    Eric> I still believe that a routine in KL_STRING_ROUTINES should
    Eric> not make such assumption as to whether the string comes from
    Eric> a parser or not.

Actually, the assumption is not that it ALWAYS comes from a parser,
but that it usually does.

In the other cases, the client can always call:

if is_integer and then is_integer_64 then

Of course you didn't like this.

It wouldn't like quite so bad if it were written as:

if is_decimal_digits and then is_integer_64 then

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.

But I'm guessing you won't like it any better.

    Eric>     if my_string.count < 19 then use INTEGER_64 else use
    Eric> MA_DECIMAL end

I had thought of that, and indeed it may be the better practical
solution (this isn't clear - runtime performance is far more important
than XPath parsing time on the whole, but the extra times that
MA_DECIMAL is needed are unlikely to occur often).

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.

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).
-- 
Colin Adams
Preston Lancashire