in reply to Iterator as a Class or Object Method

In a situation like you describe, you can frequently use a callback to achieve the result you want.

You simply pass in a subref of code you want executed for each iteration, and let the object instance method do the iteration work, and call your subref as necessary.

     "Man cannot live by bread alone...
         He'd better have some goat cheese and wine to go with it!"

  • Comment on Re: Iterator as a Class or Object Method

Replies are listed 'Best First'.
Re^2: Iterator as a Class or Object Method
by dragonchild (Archbishop) on Oct 03, 2005 at 11:07 UTC
    I agree wholeheartedly with BUU. I'm rewriting Tree::Simple right now and I completely removed the visitor interface for exactly that reason. I'll give you an iterator over me and my children and you can implement the visitor interface if it's that important to you.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Care to explain? Seems like you are against "map", "grep", and "foreach" (i.e. pass a block to a higher order function). Maybe I'm misunderstanding what a "visitor" is?
Re^2: Iterator as a Class or Object Method
by BUU (Prior) on Oct 03, 2005 at 10:28 UTC
    Please, for the love of god, File::Find is bad enough, we don't need any more modules using this hideous interface.
      Please, for the love of god, File::Find is bad enough, we don't need any more modules using this hideous interface.

      I agree that Find::File is foul - but that's more because of bad design rather than something bad with callback based APIs in general. If it passed named arguments rather than using evil globals it would be a fair bit nicer to use.

      I'm hearing unsupported objections to passing coderefs to objects.

      I will concede that this is not for the feint-of-heart - newbies find it difficult to fathom the concept, so, writers shouls probably provide an alternative interface for common goodies like File::Find.

      The larger issue, as I see it, is that coderefs provide an elegant solution such as this one. Plenty of modules use filters as properties - either as regexen or coderefs.

      To simplify caller understanding, I usually provide an alternative of pre-specifying the code-ref as an object property, then calling a method that will invoke the coderef.

      Beyond personal preferences, and perceived complexity, is there a reason NOT to use coderefs ?

           "Man cannot live by bread alone...
               He'd better have some goat cheese and wine to go with it!"