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

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

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

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> I had a look at the routines `is_integer_64' and
    Eric> `to_integer_64' in class KL_STRING_ROUTINES. And there are
    Eric> two things that I don't like. The first thing is that they
    Eric> create too many temporary objects (calling `substring',
    Eric> creating manifest arrays).
    >> Yes. I wasn't happy with that myself.
    Eric> The second thing that I don't like is the precondition
    Eric> "is_integer". I don't think that it is a good idea to have
    Eric> to write: is_integer (s) and then is_integer_64 (s)
    >> Well I thought about that.  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 think that this assumption is too strong for a general
    Eric> purpose library class like KL_STRING_ROUTINE. It would have
    Eric> been OK if this routine was part of your parsing class, but
    Eric> here with KL_STRING_ROUTINE we cannot make such an
    Eric> assumption.

Then the question is under what circumstances should `is_integer_64'
return True?
One answer that is inconsistent with your desired post-condition would
be an Eiffel INTEGER_64 literal (as it might contain
underscores). Likewise it can't contain a leading negative sign. I
still don't see any other uses for it.

In any case, I don't want to be using a routine that is doing the
additional checks, so I think it might be best if I simply remove
these routines, and add my own local routines to the XPath parser.
-- 
Colin Adams
Preston Lancashire