gobo-eiffel-develop

[gobo-eiffel-develop] Iterators for DS_TABLE?

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

Quite often I have a need to iterate over a DS_HASH_TABLE and inspect
both the item and the key. Currently I have no choice but to use a
cursor, as the features in the Iteration feature clause do not pass
the key to the agent.

It would be nice to have do_all_key, do_if_key etc. where the agent
receives both the item and the key. Ideally, these would be declared
for DS_TABLE.

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

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

Colin Adams wrote:
> Quite often I have a need to iterate over a DS_HASH_TABLE and inspect
> both the item and the key. Currently I have no choice but to use a
> cursor, as the features in the Iteration feature clause do not pass
> the key to the agent.

I sometimes have the same need.

> It would be nice to have do_all_key, do_if_key etc. where the agent
> receives both the item and the key. Ideally, these would be declared
> for DS_TABLE.

These feature names suggest that only the key is passed to the
agent. I think that we need the three kinds of iterators:
over the items, over the keys, and over both. The most difficult
part is to find names. What about `do_all', `do_all_key' and
`do_all_keyed'? Any better suggestion?

Well, in fact to iterate only on keys I guess we can do
`my_table.keys.do_all'... So, we might need only two kinds of
iterators after all. What about `do_all' and `do_all_with_key',
the latter being similar to `do_all_with_index'?

Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
I don't remember why DS_TABLE is not linear, but I'm not
currently in a mood to change that to make it linear.

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

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

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

On 20/03/2008, Eric Bezault <er...@go...> wrote:

> These feature names suggest that only the key is passed to the
>  agent. I think that we need the three kinds of iterators:
>  over the items, over the keys, and over both. The most difficult
>  part is to find names. What about `do_all', `do_all_key' and
>  `do_all_keyed'? Any better suggestion?
>
>  Well, in fact to iterate only on keys I guess we can do
>  `my_table.keys.do_all'... So, we might need only two kinds of
>  iterators after all. What about `do_all' and `do_all_with_key',
>  the latter being similar to `do_all_with_index'?

Yes, that sounds the best compromise.

>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>  I don't remember why DS_TABLE is not linear, but I'm not
>  currently in a mood to change that to make it linear.

There is nothing linear about for_all_with_keys and there_exists_with_keys.
Do_all_with_index/do_if_with_index imply a linear ordering, so we
won't want them in DS_TABLE. I see no implied linearity with
do_all_with_keys, do_if_with_keys (or for that matter do_all and
do_if, just from the names). It all depends upon what the header
comment says. So for do_all_with_keys we can just word the header
comment to state that no particular order may be relied upon. Likewise
for do_if_with_keys. Note that this will allow for concurrent
implementations using SCOOP or other concurrent technologies.

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

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

Colin Adams wrote:
> On 20/03/2008, Eric Bezault <er...@go...> wrote:
> 
>> These feature names suggest that only the key is passed to the
>>  agent. I think that we need the three kinds of iterators:
>>  over the items, over the keys, and over both. The most difficult
>>  part is to find names. What about `do_all', `do_all_key' and
>>  `do_all_keyed'? Any better suggestion?
>>
>>  Well, in fact to iterate only on keys I guess we can do
>>  `my_table.keys.do_all'... So, we might need only two kinds of
>>  iterators after all. What about `do_all' and `do_all_with_key',
>>  the latter being similar to `do_all_with_index'?
> 
> Yes, that sounds the best compromise.
> 
>>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>>  I don't remember why DS_TABLE is not linear, but I'm not
>>  currently in a mood to change that to make it linear.
> 
> There is nothing linear about for_all_with_keys and there_exists_with_keys.
> Do_all_with_index/do_if_with_index imply a linear ordering, so we
> won't want them in DS_TABLE.

I should have said that DS_TABLE is not a descendant of
DS_TRAVERSABLE (rather than a descendant of DS_LINEAR).

I would say that `do_all_with_index' belongs to DS_INDEXABLE.
It has been added to DS_LINEAR for convenience (perhaps
DS_LINEAR should have been a descendant of DS_INDEXABLE).

> I see no implied linearity with
> do_all_with_keys, do_if_with_keys (or for that matter do_all and
> do_if, just from the names). It all depends upon what the header
> comment says. So for do_all_with_keys we can just word the header
> comment to state that no particular order may be relied upon. Likewise
> for do_if_with_keys. 

If we follow the same reasoning, that `do_all', `there_exists',
etc. should be moved to DS_CONTAINER.

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

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

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

Eric Bezault wrote:
> Colin Adams wrote:
 >> Eric Bezault wrote:
>>>  Well, in fact to iterate only on keys I guess we can do
>>>  `my_table.keys.do_all'... So, we might need only two kinds of
>>>  iterators after all. What about `do_all' and `do_all_with_key',
>>>  the latter being similar to `do_all_with_index'?
>> Yes, that sounds the best compromise.

Done. I did `do_all_with_key' and `do_if_with_key' because
we already had similar routines for `do_all_with_index' and
`do_if_with_index'. Since we didn't have `for_all_with_index'
and `there_exists_with_index', I didn't provide the `..._with_key'
counterpart either.

>>>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>>>  I don't remember why DS_TABLE is not linear, but I'm not
>>>  currently in a mood to change that to make it linear.
>> There is nothing linear about for_all_with_keys and there_exists_with_keys.
>> Do_all_with_index/do_if_with_index imply a linear ordering, so we
>> won't want them in DS_TABLE.
> 
> I should have said that DS_TABLE is not a descendant of
> DS_TRAVERSABLE (rather than a descendant of DS_LINEAR).
> 
> I would say that `do_all_with_index' belongs to DS_INDEXABLE.
> It has been added to DS_LINEAR for convenience (perhaps
> DS_LINEAR should have been a descendant of DS_INDEXABLE).
> 
>> I see no implied linearity with
>> do_all_with_keys, do_if_with_keys (or for that matter do_all and
>> do_if, just from the names). It all depends upon what the header
>> comment says. So for do_all_with_keys we can just word the header
>> comment to state that no particular order may be relied upon. Likewise
>> for do_if_with_keys. 
> 
> If we follow the same reasoning, that `do_all', `there_exists',
> etc. should be moved to DS_CONTAINER.

I moved `do_all', `do_if', `there_exists' and `for_all' to
class DS_CONTAINER. And the `..._with_key' routines have
been introduced in class DS_TABLE.

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

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Berend de B. <be...@po...>]

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

    Eric> Well, in fact to iterate only on keys I guess we can do
    Eric> `my_table.keys.do_all'... So, we might need only two kinds of
    Eric> iterators after all. What about `do_all' and
    Eric> `do_all_with_key', the latter being similar to
    Eric> `do_all_with_index'?

Or for_each which gives both item and key, and for_each_item which only
does the item?

What I try to come up with is the shortest name, the default, for the
most common method. And a slightly longer for the other.

Or else, a name with both key and item is longer, so make it the default
when nothing is in the feature name, as it is really hard to indicate
you get both, so you can put that in the comments.

And iterating while receiving a single feature is then simply
for_each_item/for-each_key.

-- 
All the best,

Berend de Boer

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

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

Berend de Boer wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Well, in fact to iterate only on keys I guess we can do
>     Eric> `my_table.keys.do_all'... So, we might need only two kinds of
>     Eric> iterators after all. What about `do_all' and
>     Eric> `do_all_with_key', the latter being similar to
>     Eric> `do_all_with_index'?
> 
> Or for_each which gives both item and key, and for_each_item which only
> does the item?
> 
> What I try to come up with is the shortest name, the default, for the
> most common method. And a slightly longer for the other.
> 
> Or else, a name with both key and item is longer, so make it the default
> when nothing is in the feature name, as it is really hard to indicate
> you get both, so you can put that in the comments.
> 
> And iterating while receiving a single feature is then simply
> for_each_item/for-each_key.

I think that we are better off using the same names as in EiffelBase.
EiffelBase uses `do_all' and `do_all_with_index'. I think that
`do_all_with_key' follows this pattern.

Also, if in linear we had `for_each' which gets the items, I would
not want that name to be changed to `for_each_item' in tables
or in arrays (so that `for_each' could now, inconsistently, get
items and keys in tables or items and indexes in arrays).

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