Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#159 Add ITEMS method to .Supplier

Rejected
closed
nobody
Classes (154)
5
2012-08-14
2007-04-19
No

If one receives a supplier object, but has no means to get independently to the collection itself (e.g. the suppliers that get returned by .Class' METHODS or .Object's INSTANCEMETHODS and the like), then it is not possible to learn about the total numbers of index/items pairs in the supplier object.

Supplying an ITEMS method which returns the total number of index/items pairs would solve this.

Discussion

  • Rick McGuire
    Rick McGuire
    2007-04-19

    Logged In: YES
    user_id=1125291
    Originator: NO

    I'm not sure this is particularly doable. A supplier is intended as an iterator for situations where you might be doing a lazy fetch of the results. In those cases, it is not known if there is even a next item until the supplier~available method is invoked. Adding an items capability places a whole new requirement on supplier instances that they are required to have forward knowledge of item availability.

     
  • Logged In: YES
    user_id=662126
    Originator: YES

    The present .Supplier class method NEW expects two array objects, where it would be feasible to return the items of either array object. This therefore seems to be the general use case of supplier.


    Of course, I see your point about a hypothetical/potential "lazy" supplier. How about either creating a subclass .LazySupplier which has the ITEMS method removed (or a mixin marker), or in general having lazy suppliers return something like -1 or .nil?

     
  • Rick McGuire
    Rick McGuire
    2007-04-19

    Logged In: YES
    user_id=1125291
    Originator: NO

    That is only one specific implementation of supplier. The supplier model does not have to conform to that issue. This is an issue that should be discussed on the dev list. If there is consensus that this should be done and we're clear on what the expected behavior of other polymorphic suppliers should be when sent an items message, then I'll allow this. I've also at times wanted allItems and allIndexes, but have held off because of this issue.

    I'm more than willing to add this if everybody is clear on the implications for other potential supplier uses (such as a database cursor, for example).

     
  • Rick McGuire
    Rick McGuire
    2007-06-04

    Logged In: YES
    user_id=1125291
    Originator: NO

    Notice:
    This RFE is slated to be rejected.

    Reason: The requested feature is outside of the design scope of the supplier class.

    Suppliers are intended to support a lazy retrieval semantic where it is not necessarily certain how many items are available in advance. For example, the StreamSupplier class used by the .stream supplier method functions that way. Adding this to the supplier class creates an expectation that all suppliers must implement the method, which might not even be possible.

    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.

     
  • Rick McGuire
    Rick McGuire
    2007-07-16

    Logged In: YES
    user_id=1125291
    Originator: NO

    This RFE has now passed the 30-day mark since rejection without appeal. This RFE is now closed.

     


Anonymous


Cancel   Add attachments