Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

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

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

    Eric> OK, but during the sort there is no guarantee that all items
    Eric> in the list will be compared with all other items. So in
    Eric> theory I guess it is possible to sort a list containing two
    Eric> non comparable items without comparing them explicitly, and
    Eric> hence without raising the exception.

An interesting point. I'm not sure.
The definition of the error code is:

"It is a non-recoverable dynamic error if, for any sort key component,
the set of sort key values evaluated for all the items in the initial
sequence, after any type conversion requested, contains a pair of
ordinary values for which the result of the XPath lt  operator is an
error." 

I'm not sure if I can follow the English involved. But I THINK it
means that whether or not a comparison is actually performed on the
pair involved, the error must still be raised.

In which case:

    Eric> Anyway, if you want to report an XPath error, then I guess
    Eric> that the proper way to do it is to write a routine that
    Eric> takes the list as argument and returns true or false
    Eric> depending on whether the list contains non comparable items
    Eric> or not. If yes, then report the error, if not, the call `sort'.

the above approach is actually necessary (although more expensive) if
non-comparability is not transitive. I must dig into this.

    Eric> In any case I really think that you need to use
    Eric> KL_PART_COMPARATOR and not KL_COMPARATOR in order to avoid
    Eric> having to raise an exception in the implementation, because
    Eric> the contracts in class KL_COMPARATOR are not applicable in
    Eric> your case.

I still don't see why inheriting from KL_PART_COMPARATOR would make a
difference.
Anyway, XM_XPATH_ATOMIC_COMPARER needs to inherit from KL_COMPARATOR
as less_equal is used elsewhere (XM_XPATH_MINIMAX_ROUTINES).
-- 
Colin Adams
Preston Lancashire