Re: [gobo-eiffel-develop] Errors caught by gelint in XM_XPATH classes

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

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

    Eric> Hmmm, are you sure you don't want to use inline agents?
    Eric> Look at how lovely it would look like:

    Eric>    no_void_item: not a_list.there_exists (agent (v: G):
    Eric> BOOLEAN do Result := v = Void end)

Yuk!
And you forgot the header comment and postcondition.

As an aside, I will now explain why I think that your opinion "that
using a call agent instead of an inline agent pollutes the API" is
mistaken.

I hold to the traditional meaning of Application Program Interface as:

"A set of feature calls that a service provides to its clients".

Note that I distinguish between the API, the ADT, and the class
interface (the set of features exported to ANY).

We know from DbC that one such service is the ability to check that
all preconditions hold prior to calling a feature. Therefore a call to
evaluate a postcondition is an inherent part of the API. 

So distinguishing between feature calls and expression evaluation is
not helpful in my opinion. It goes against the principle of
uniformity.

Another way of expressing this is that I don't believe that the
class interface should be identical to the ADT (and in fact no Eiffel
class ever written has this property).

    Eric> ;-)) OK, let's try another solution. In order to have
    Eric> something that looks as terse and readable as possible in
    Eric> the client code, I would suggest adding a feature `has_void'
    Eric> in DS_SEARCHABLE and then write your assertion as follows:

    Eric>   no_void_item: not a_list.has_void

    Eric> We should note that ARRAY has a feature `all_default', so
    Eric> having `has_default' in DS_SEARCHABLE might look more
    Eric> consistent. But it is not really what we want to express in
    Eric> the assertion, even though in your case the result would be
    Eric> the same.

    Eric> What's your opinion?

I would prefer has_void as it is more explicit (no need for the reader
to reason out that has_default mean has (Void) rather than has (0)
when G = INTEGER_REF).
-- 
Colin Adams
Preston Lancashire