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