>Further to the earlier discussion, I thought some might find this
>auto-response I got from mailing one CPAN author funny:
>-----
>I am preparing to or have deployed with my National Guard unit for
> federal active duty. I may not be able to access or read my email
Funny in an amusing way? Or funny as bad?
Funny as in, now it's not about dead camels, rather hibernating
camels, an aspect the conversation did not really focus on.
Fortunately as he's looked after this responsibility it's not funny as
in bad. There's also the distinctly unfunny side of it, and my
thoughts go out to Brian in that regard.
I now co-own everything in BDFOY's CPAN land, and his home page has a
"CPAN power of attorney" pointing at me or Randal. What did you need
help with?
It's about Object::Iterate; I have a module to be released that will
supply some extra forms of map (eg, Tye McQueen's mapcar), and wanted
to produce iterative versions of them too. Therefore, it would be
good to form a standardised set of semantics for iterators.
I quite liked MJD's semantics for using a CODE ref as an iterator; it
certainly makes the code simple. OTOH, I appreciate that it's not OO
clean, so the Object::Iterate approach might be considered better by
some. This calls for hybrid semantics IMHO.
The question is, what should those semantics be, and should/how can
Object::Iterate form a convenient `adapter' for the differing
conventions?
These are the conventions I've seen used:
->__next__ (Object::Iterate)
->() (MJD-style)
->get_next (SPOPS-style)
->next (Tangram::Cursor, File::Iterator,
Data::Iterator::EasyObj, etc)
Also, there are some stickier points; such as - is it reasonable to
assume that if an iterator returns `undef' that it's finished? Should
there be a similar set of conventions for resetting or un-getting
items from the iterator?
--
Sam Vilain, [EMAIL PROTECTED]
Real software engineers don't program in assembler. They become
queasy at the very thought.
