Backward iterators

[Colin Paul Adams]

In several places in the XSLT library, I have to process structures
backwards, using new_cursor, finish, before. This precludes converting
the loops to using agents with do_all, do_if etc. This will annoy
Franck.

Well, I have no objection to annoying Franck, since he won't fix the
bugs in the XML parser. But if he decides to do so, can we reward him
with backward iterators?
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

[Eric Bezault]

Colin Paul Adams wrote:
> In several places in the XSLT library, I have to process structures
> backwards, using new_cursor, finish, before. This precludes converting
> the loops to using agents with do_all, do_if etc. This will annoy
> Franck.
>
> Well, I have no objection to annoying Franck, since he won't fix the
> bugs in the XML parser. But if he decides to do so, can we reward him
> with backward iterators?

I thought about that as well. I think that I was the first one
to explicitly state in the header comments that the iterators
are traversing from first to last. Which of course raises the
issue that we miss the iterators from last to first. We also
probably miss a few other possible iterators such as do_until.
Any naming convention for the backward iterator feature names?

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

[Colin Paul Adams]

>>>>> "Eric" == Eric Bezault <[hidden email]> writes:

    Eric> I thought about that as well. I think that I was the first
    Eric> one to explicitly state in the header comments that the
    Eric> iterators are traversing from first to last. Which of course
    Eric> raises the issue that we miss the iterators from last to
    Eric> first. We also probably miss a few other possible iterators

There is a class in EiffelBase, called something like LINEAR_ITERATOR
that has a whole lot of variants. It might be worth taking a look at
(but with caution - when I last looked at it, it was a real mess - at
least as far as contracts went. i raised the issue with Manu, and they
did something about it, but i haven't looked at it to see what0.

    Eric> such as do_until.  Any naming convention for the backward
    Eric> iterator feature names?

*_backwards seems straight-forward.

E.g do_all_backwards, do_if_backwards and do_all_with_index_backwards
all read ok.

It would be more compact to drop the all, but then we get an
inconsistent pattern:

do_backwards, do_if_backwards, do_backwards_with_index.

Still, I think I prefer these shorter names.
If we were starting from scratch, I would definitely go for this,
along with fo_forwards, etc., rather than do_all.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

[Eric Bezault]

Colin Paul Adams wrote:

>>>>>> "Eric" == Eric Bezault <[hidden email]> writes:
>
>     Eric> I thought about that as well. I think that I was the first
>     Eric> one to explicitly state in the header comments that the
>     Eric> iterators are traversing from first to last. Which of course
>     Eric> raises the issue that we miss the iterators from last to
>     Eric> first. We also probably miss a few other possible iterators
>
> There is a class in EiffelBase, called something like LINEAR_ITERATOR
> that has a whole lot of variants. It might be worth taking a look at
> (but with caution - when I last looked at it, it was a real mess - at
> least as far as contracts went. i raised the issue with Manu, and they
> did something about it, but i haven't looked at it to see what0.
>
>     Eric> such as do_until.  Any naming convention for the backward
>     Eric> iterator feature names?
>
> *_backwards seems straight-forward.

My dictionary says that Americans use "backward" instead
of "backwards".

> E.g do_all_backwards, do_if_backwards and do_all_with_index_backwards
> all read ok.
>
> It would be more compact to drop the all, but then we get an
> inconsistent pattern:
>
> do_backwards, do_if_backwards, do_backwards_with_index.
>
> Still, I think I prefer these shorter names.
> If we were starting from scratch, I would definitely go for this,
> along with fo_forwards, etc., rather than do_all.

We could have the forward(s) and backward(s) versions,
and have `do_all' use one or the other (when people
don't care about the direction of the traversal). For
example in DS_CONTAINER we have `do_all' since we don't
really know or care about traversal directions. In
class DS_LINEAR it could be implemented using
`do_forward(s)'.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

[Colin Paul Adams]

>>>>> "Eric" == Eric Bezault <[hidden email]> writes:

    >> *_backwards seems straight-forward.

    Eric> My dictionary says that Americans use "backward" instead of
    Eric> "backwards".

There's a subtle difference in meaning in England, in that the former
could be construed as a slight. But i don't object.


    Eric> We could have the forward(s) and backward(s) versions, and
    Eric> have `do_all' use one or the other (when people don't care
    Eric> about the direction of the traversal). For example in
    Eric> DS_CONTAINER we have `do_all' since we don't really know or
    Eric> care about traversal directions. In class DS_LINEAR it could
    Eric> be implemented using `do_forward(s)'.

That sounds good to me. You might try selling it to Manu for Free ELKS
too. There wouldn't be any compatibility (I left out the preceding
adjective :-) ) problem, either.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

[Paul Morgan-4]

On Sat, Nov 1, 2008 at 1:52 PM, Colin Paul Adams
<[hidden email]> wrote:
>>>>>> "Eric" == Eric Bezault <[hidden email]> writes:
>
>    >> *_backwards seems straight-forward.
>
>    Eric> My dictionary says that Americans use "backward" instead of
>    Eric> "backwards".
>
> There's a subtle difference in meaning in England, in that the former
> could be construed as a slight. But i don't object.

FWIW:

backward and backwards both have negative connotations in the US.
When used appropriately here, they both refer to a static orientation.

For movement, we use forward and reverse.

-paul

>
>
>    Eric> We could have the forward(s) and backward(s) versions, and
>    Eric> have `do_all' use one or the other (when people don't care
>    Eric> about the direction of the traversal). For example in
>    Eric> DS_CONTAINER we have `do_all' since we don't really know or
>    Eric> care about traversal directions. In class DS_LINEAR it could
>    Eric> be implemented using `do_forward(s)'.
>
> That sounds good to me. You might try selling it to Manu for Free ELKS
> too. There wouldn't be any compatibility (I left out the preceding
> adjective :-) ) problem, either.
> --
> Colin Adams
> Preston Lancashire
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gobo-eiffel-develop mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop