gobo-eiffel-develop

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

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

Gelint reports the following errors:

[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (33,25): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (46,25): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (205,21): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (33,25): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (46,25): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (174,21): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----

One way to solve this problem is to use inline agents ;-)))
Anyway, the assertions are obviously wrong, it should be:

   no_void_item: not a_list.has (Void)
                 ^^^
Probably not caught earlier because of the bug in gexace.

OK, I can feel the fact that you don't want to use inline
agents. So, there are several other solutions.

1) Add a routine `has_default' in class DS_SEARCHABLE.

2) Add a routine `default_item: G' in your class and
    call: not a_list.has (default_item). But this will
    not be practical for assertions in creation routines.

3) Use KL_ANY_ROUTINES.same_objects:
     not a_list.there_exists (agent ANY_.same_objects (?, Void))

Solution 3 is the one which will work without any additional
code.

PS: I would tend to avoid declaring the generic parameter
as 'reference G' because it is not part of ECMA Eiffel is
I remember correctly.

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

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

[Colin A. <col...@go...>]

I will deal with this next weekend, as I only have a laptop this weekend.
Also Unicode 5.1 has been released a week ago, so I will prepare an
update for that too.

On 10/04/2008, Eric Bezault <er...@go...> wrote:
> Gelint reports the following errors:
>
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (33,25): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (46,25): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (205,21): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (33,25): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (46,25): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (174,21): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>
>  One way to solve this problem is to use inline agents ;-)))
>  Anyway, the assertions are obviously wrong, it should be:
>
>    no_void_item: not a_list.has (Void)
>                  ^^^
>  Probably not caught earlier because of the bug in gexace.
>
>  OK, I can feel the fact that you don't want to use inline
>  agents. So, there are several other solutions.
>
>  1) Add a routine `has_default' in class DS_SEARCHABLE.
>
>  2) Add a routine `default_item: G' in your class and
>     call: not a_list.has (default_item). But this will
>     not be practical for assertions in creation routines.
>
>  3) Use KL_ANY_ROUTINES.same_objects:
>      not a_list.there_exists (agent ANY_.same_objects (?, Void))
>
>  Solution 3 is the one which will work without any additional
>  code.
>
>  PS: I would tend to avoid declaring the generic parameter
>  as 'reference G' because it is not part of ECMA Eiffel is
>  I remember correctly.
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  gobo-eiffel-develop mailing list
>  gob...@li...
>  https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

[gobo-eiffel-develop] Generator clause for geuc

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

>>>>> "Colin" == Colin Adams <col...@go...> writes:

    Colin> I will deal with this next weekend (gelint violations on
    Colin> XPath classes), 

Done. Check-in some time in the future.

    Colin> this weekend.  Also Unicode 5.1 has been released a week
    Colin> ago, so I will prepare an update for that too.

Geuc currently writes a remark indexing term indicatring that is
generated the class.

I am changing this to:

"%Tgenerator: %"geuc%"%N%N"

Do I need to edit older classes (i.e. Unicode 4.1 and 5.0)?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Generator clause for geuc

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

Colin Paul Adams wrote:
> Geuc currently writes a remark indexing term indicatring that is
> generated the class.
> 
> I am changing this to:
> 
> "%Tgenerator: %"geuc%"%N%N"
> 
> Do I need to edit older classes (i.e. Unicode 4.1 and 5.0)?

I guess so.

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

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

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Gelint reports the following errors: [VUAR-2] class
>     Eric> XM_XPATH_ARRAY_LIST_ITERATOR (33,25): the 1-th actual
>     Eric> argument (of type 'NONE') does not conform to the
>     Eric> corresponding formal argument (of type 'G') of feature `has'
> 
>     Eric> 3) Use KL_ANY_ROUTINES.same_objects: not a_list.there_exists
>     Eric> (agent ANY_.same_objects (?, Void))
> 
>     Eric> Solution 3 is the one which will work without any additional
>     Eric> code.
> 
> ISE 6.1 is rejecting this with:
> 
> Error code: VUAR(2)
> Type error: non-conforming actual argument in feature call. 
> What to do: make sure that type of actual argument conforms to type
>   of corresponding formal argument. 
> 
> Class: XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR [G -> XM_XPATH_ITEM]
> Feature: make
> Called feature: there_exists (a_test: FUNCTION [ANY, TUPLE [G], BOOLEAN]): BOOLEAN from DS_INDEXABLE
> Argument name: a_test
> Argument position: 1
> Actual argument type: PREDICATE [KL_ANY_ROUTINES, TUPLE [ANY]]
> Formal argument type: FUNCTION [ANY, TUPLE [Generic #1], BOOLEAN]
> Line: 37
>         list_not_empty: not a_list.is_empty
> ->      no_void_item: not a_list.there_exists (agent ANY_.same_objects (?, Void))
>       do

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

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

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

   no_void_item: not a_list.has_void

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

What's your opinion?

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

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

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

Colin Paul Adams wrote:
> 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).

Feature `has_void' is now available in SVN.

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

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

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

Eric Bezault wrote:
> Colin Paul Adams wrote:
>> 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).
> 
> Feature `has_void' is now available in SVN.

You should also note that the header comment of the creation
procedures of these two classes (XM_XPATH_ARRAY_LIST_ITERATOR
and XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR) are missing.

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

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