Anyone rolled these two together? Experiences, positive or otherwise?
For my WebService::ISBNDB package, I'm working on implementing a HOP-style iterator to return when the user does a search. Some searches, especially when vague, could return well into the hundreds (if not thousands) of matches. Add to that the fact that the service only returns data in pages of 10, and an iterator that hides all this hassle from the user makes sense.
What also makes sense, though, is expecting something like that sort of search to return an array, or at least an array reference; one that can be manipulated with pop, shift, etc. Even push and unshift, though in this case I would imagine one might not want to allow adding to such an array (you can always copy what you want to a separate array and add in whatever else you need).
Enter tied arrays. The TIEARRAY method doesn't have to return an array reference. Even the perltie man-page uses a hash-reference for the examples under "Tying Arrays".
Enter, from the other side of the stage, that new darling of the Perl OO community, the inside-out object. Which I've enjoyed working with in this very project. So why not try getting some of that peanut butter in my chocolate? Obviously TIEARRAY can return an IOO. And when you call tie, it has an actual return value, the referent that TIEARRAY returns (or TIESCALAR, TIEHASH, etc. as apropos). You could (conceivably) then choose to use the core object with methods like next, first or all. Or you could use the tied array, with the usual array-related operations.
Of course, there would be issues whether or not you wanted the "array" to be mutable via slicing operations, what to do if the user addresses both the iterator and array interfaces, etc. But it gets me to thinking, and that often comes of no good...
