Hi Mike That's the Aviad Ben Dov method mentioned in the article. I'm not sure as to the state of that project as Aviad has described it as broken in a reply to my article.
Jim 2008/10/15 mikeb01 <[EMAIL PROTECTED]>: > > There is a yield implementation that is implemented using byte code > modification to get the same functionality: > > http://code.google.com/p/infomancers-collections/ > > Mike. > > On Oct 16, 1:17 am, "Jim Blackler" <[EMAIL PROTECTED]> wrote: >> Absolutely, the first option would be to return your own iterator and >> handle the logic in that. It would be easier to debug and you'd have >> no threading issues. >> >> Where it is difficult to do that is when the calculating algorithm >> uses recursion. For the examples of my yield return library I wrote an >> algorithm that returns all combinations a word might have its letters >> rearranged into, with no repeats. This uses recursion. A function >> takes a StringBuffer and an array of letter frequencies. For each >> letter in turn it is added to the string buffer, removed from the >> frequency array and if any letters remain the function calls itself >> back. >> >> I attempted to write an alternative version that had all its logic in >> an iterator.next(). I expected this to be longer and more complex than >> the version that used recursion. However In the hour or so I put aside >> for the task I couldn't even get a version working. I'm sure its >> possible, but I learned that it can be extremely difficult to convert >> from an algorithm that uses recursion and sends results during the >> collection, to one that calculates each value on demand. >> >> Jim >> >> 2008/10/15 Christian Catchpole <[EMAIL PROTECTED]>: >> >> >> >> > Obviously, you might try to write algorithms that operate as normal >> > iterators. I would be avoiding the multi-thread model if possible. >> > The yield approach I guess if for cases where this isn't practical. >> >> > I was thinking that you could even use this as an aggregator for >> > multiple threads. For example, multiple HTTP service threads could >> > all be delivering objects to a single iterator, which iterates >> > forever, processing the results on a single thread. >> >> > On Oct 13, 8:50 pm, Casper Bang <[EMAIL PROTECTED]> wrote: >> >> Very cool, continuations is another thing we need to bring down >> >> ceremony and housekeeping in Java. I would think your impl stands a >> >> better chance at being adopted into Java than Aviad Ben Dov's Yielder, >> >> although I am not sure about the (performance?) drawbacks of either >> >> over native support. >> >> >> /Casper >> >> >> On Oct 12, 11:20 pm, "Jim Blackler" <[EMAIL PROTECTED]> wrote: >> >> >> > Hello all >> >> >> > I've just finished a little library and article about my efforts to >> >> > emulate a form of C#'s yield return in Java. >> >> >> > It uses a new thread and a SynchronousQueue object to enable any >> >> > calculating function to return its output through a standard Java >> >> > iterator. >> >> >> > The post is here ..http://jimblackler.net/blog/?p=61 >> >> >> > I'd be interested in any views. >> >> >> > Jim > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
