#176 Please supply a new class \"Cursor\" for oredered collections

v3.2.0
closed
nobody
Classes (154)
5
2012-08-14
2007-05-30
No

Half a year ago a discussion came up with regards to defining a "Cursor" class for ordered collection. This should be done in a way, which makes it possible to use multiple cursors independently of each other, even if they refer to the same ordered collection object.

As promised to come back with a suggestion for a "Cursor" class in the discussion back then, this RFE submits one.

Suggestion: the "Cursor" class should maintain the collection object and a single index object referring to that colleciton object. The "Cursor" should supply the methods:

  • collectionObject
  • index
  • first
  • last
  • next
  • previous

"collectionObject" returns the collection object for which the cursor object got created.

"index" returns the index value that was returned the last time one of the methods "first", "last", "next", "previous" was run.

"first" and "last" must not have an argument supplied. The message gets forwarded to the "collectionObject" and the return value will be saved in the attribute "index".

"next" and "previous" may supply an index value, if not, then by default the value of "index" is used. The message gets forwarded to the "collectionObject" and the return value will be saved in the attribute "index".


Enclosed please find an implementation of this suggested "Cursor" class. It is excercised as an example against an array object, using two different cursors for it.


In order to be functional for the ordered collection classes, the "Queue" class would need to gain the methods "first", "last", "next", and "previous" as requested in another RFE.

Discussion

  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    Did update the 'Cursor' specs to allow for 'circular' cursors. I.e., they will wrap, if moving beyond the end (beginning) of the underlying ordered collection. By default 'circular' is .false, but can be changed to .true by the programmer.

    In the case that a circular cursor is used to move beyond the end/beginning of the underlying collection, raised errors (e.g. from List or Queue objects) will be intercepted, to let the revolving succeed.
    File Added: Cursor.rex

     
  • Rony G. Flatscher

    'Cursor' class as of 2007-06-02 23:41

     
  • Rony G. Flatscher

    Example program which uses 'Cursor' in non-circular and circular mode (tested with all current ordered classes).

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    File Added: useCursor.rex

     
  • Rick McGuire

    Rick McGuire - 2007-06-12

    Logged In: YES
    user_id=1125291
    Originator: NO

    I'm ok with the concept of this class, but there are some details of the suggested implementation I'm not completely comfortable with.

    1) I'm not sure Cursor is the most appropriate name, particularly since we don't have a concept of package qualifiers yet. I'm concerned there may be potential future conflicts with other classes where Cursor is a more appropriate name. Iterator might be a better choice.

    2) I'm not completely comfortable with allowing the circular mode to be switched on and off. And I'm not particularly fond of how the wrapping is implemented using signal on syntax. Given what's being done in the code, I think I'd be happier with two different implementation classes.

    3) I think the "collectionObject" method should be shortened to "collection".

    4) The index method should validate the position at the time it is set, not delay validation until it is used.

     
  • Rony G. Flatscher

    Defines the classes "Iterator" and "CircularIterator"

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    There will be two files uploaded, one "Iterator.rex" containing the definition of the classes "Iterator" and its subclass "CircularIterator". The other file "useIterator.rex" is a short program demoing the features with an Array, CircularQueue, List, and Queue.

    If the index value is set explicitly the hasindex() method of the collection will be used to determine whether the index is valid or not. If it is not valid an error 93.900 with the message 'Collection has no item associated with the supplied index "newIndex".' is given; if hasindex() raises an error it will be propagated.

    "useIterator.rex" will demonstrate assigning an non-existent index-value.

    File Added: Iterator.rex

     
  • Rony G. Flatscher

    Rexx program that demonstrates the usage of "Iterator" and "CircularIterator"

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    File Added: useIterator.rex

     
  • Rick McGuire

    Rick McGuire - 2007-06-14

    Logged In: YES
    user_id=1125291
    Originator: NO

    I was getting this ready for integration, and I realized this class is not doing what I believed an iterator should be doing. This implementation is returning the index of the of the next/previous item rather than the item itself. A cursor implementation should just be returning the item associated with an index and should not require that the user have access to the wrappered collection class to retrieve anything. This essentially just duplicates the function of next/previous, but just replaces the variable holding the current index with a variable holding a reference to the iterator, which holds the current index.

    Additionally, you have to make two separate calls for each item to use this (one to advance the index, one to retrieve the index to access the item). A useful cursor implementation would return the current item and automatically advance to the next position. It probably would require an "available" method to detect the end of the sequence.

    It would also be nice if this could support a remove method, to remove the item at the current index and adjust the position accordingly. This is pretty easy to implement with array/list, but a little more difficult for queue since the indexes shift on a remove.

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    Sorry for coming back so late, have been really swamped (and still am to a large extent).

    From your comment I see that you really are thinking of an Iterator, where I am have been truly thinking of a Cursor.

    If you remember, I had the cursor functionality originally implemented in the CircularQueue class. You pointed out use cases where different parts of a program might be in a need to use a cursor, and in multithreaded environments this would be error prone. Hence, my original submission (now that the ordered collections possess all the needed methods for positioning) of a Cursor class. A cursor would interact with a life (not a snapshot!) collection and as such needs to tackle situations where an item in the collection is not available all of a sudden; this imposes the need to signal that this has happened.

    Now, I had always also wanted an Iterator to supplement the Supplier. Just coded one up, which allows - like Supplier - to iterate over any collection in any direction, including the ability to position on a certain index/item pair. The Iterator class - like the Supplier - will work on a snapshot of the collection; will post the code and a program using it with a separate comment.

    Please note: I explicitly refrain from supplying/suggesting a "CircularIterator"! The added functionality is trivial and just would add "class-clutter" to ooRexx, which should remain as lean and simple at its interfaces as possible! Or with other words: I consider adding a (mostly superfluous) "Circular" version of Iterator as harmful for ooRexx. [Will come up with an attempt to communicate why in the next days; having come to this conclusion by looking over the current 3.2.0 beta and some RFEs in that context.]

     
  • Rick McGuire

    Rick McGuire - 2007-10-03

    Logged In: YES
    user_id=1125291
    Originator: NO

    This RFE was sort superceded by the Iterator RFE, so is going to be rejected.

     
  • Rick McGuire

    Rick McGuire - 2007-10-03

    Logged In: YES
    user_id=1125291
    Originator: NO

    Notice: This RFE is slated to be rejected.

    Reason: See the RFE item in the SourceForge Tracker system for the rejection reason.

    To appeal this rejection please contact the Appeals Committee via Mr. Chip Davis

    oorexx-rfe-appeals@oorexx.org

    All further correspondence on this RFE should be directed to the Appeals Committee and MUST include this RFE number.

    The decision of the Appeals Committee is final.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks