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 -~----------~----~----~----~------~----~------~--~---
