On Tue, Feb 14, 2012 at 3:00 PM, Bruno P. Kinoshita <brunodepau...@yahoo.com.br> wrote: > Hi all, > > Looks like the initial code [1] for the Generators API in Apache Commons > Functor was created based on the Python generators [2]. > > After playing for a while with Python generators, I realized many examples > have a 'generator', a 'range' and a 'yield' statement. Then I looked for > existing Java API's with generators, ranges and/or *yields* to have more > ideas for [functor]'s Generator API. > > I found one [3] that requires some bytecode manipulation, and another one [4] > that uses a threading mechanism to yield objects. > > I tried both of them [5] and the latter, java-yielder, seems to provide a > useful Yield API, as well as Generator and Ranges. There are few > modifications that I would like to see in its Range, like the possibility to > make the boundary values inclusive or exclusive (like in Google Guava). As > well as include a StoppableGenerator interface to the Generator API, so we > could maintain the existing implementations in [functor] of Generators. > > > If there are no objections, I will fill an issue in JIRA for enhancements on > the Generator API in [functor], where we can further discuss on this issue as > well as attach patches :-) I believe we could have similar separation in > [functor], Generators, Ranges, and maybe, Yields. However, it would be good > if someone else could have a look on java-yielder and other existing Yields > implementations for Java. > > > And if everybody thinks it is appropriate and the API is good enough, maybe > we could ping the author of java-yielder and see if he would be willing to > donate the code to ASF? It is licensed under the BSD-License [6], not sure if > it is compatible with the Apache License. >
Bruno, I will try to take a look at this this week. If we like its API and java-yielder's author/s are willing to grant us a license, that's great. However, I would urge you not to look at their actual code, rather looking at APIs only. This way you can be sure that any patches you may provide [functor] are free and clear from an IP perspective. br, Matt > > Looking forward to hearing your thoughts on this! > > > [1] > http://markmail.org/message/rtnn2xpudw3ygtvr#query:+page:1+mid:ynfmtd4shswtuvz7+state:results > > [2]http://www.dabeaz.com/generators/ > > [3] http://code.google.com/p/infomancers-collections/ > > [4] http://code.google.com/p/java-yield/ > [5] > https://github.com/kinow/yields-tests/tree/master/src/main/java/sample/yield > [6] http://www.opensource.org/licenses/bsd-license.php > > > Cheers, > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > >>________________________________ >> From: Adrian Crum <adrian.c...@sandglass-software.com> >>To: Commons Developers List <dev@commons.apache.org> >>Sent: Tuesday, 24 January 2012 7:21 PM >>Subject: Re: [functor] CharacterRange, FloatRange, DoubleRange and >>open/closed intervals >> >>After looking at the Lang 3 Range API, I realized an Iterator factory >>should be kept external to the Range class: >> >>Range<Date> dateRange = Range.between(thisMonth, nextMonth); >>Iterator<Date> dayIterator = RangeIteratorFactory.getInstance(dateRange, >>Calendar.DATE); >> >>Range<Integer> intRange = Range.between(firstInt, lastInt); >>Iterator<Integer> intSeqIterator = >>RangeIteratorFactory.getInstance(intRange, 3); >> >>-Adrian >> >>On 1/24/2012 9:10 PM, Bruno P. Kinoshita wrote: >>> >>> Sounds great for me too :) >>> >>> >>> Cheers, >>> >>> >>> Bruno P. Kinoshita >>> http://kinoshita.eti.br >>> http://tupilabs.com >>> >>> >>> ----- Mensagem original ----- >>>> De: Adrian Crum<adrian.c...@sandglass-software.com> >>>> Para: Commons Developers List<dev@commons.apache.org> >>>> Cc: >>>> Enviadas: Terça-feira, 24 de Janeiro de 2012 18:30 >>>> Assunto: Re: [functor] CharacterRange, FloatRange, DoubleRange and >>>> open/closed intervals >>>> >>>> On 1/24/2012 8:15 PM, Matt Benson wrote: >>>>> Thanks for your interest, Adrian! Comments inline: >>>>> >>>>> On Tue, Jan 24, 2012 at 1:58 PM, Adrian Crum >>>>> <adrian.c...@sandglass-software.com> wrote: >>>>>> On 1/24/2012 6:58 PM, Matt Benson wrote: >>>>>>> IMO the difference between [lang]'s and [functor]'s range >>>> concepts is that >>>>>>> those in [lang] are intended to be able to say whether a given >>>> value is in >>>>>>> the Range, but, with the exception of CharRange (this class is not >>>> even >>>>>>> public), they make no provision for iterating over members of the >>>> range. I >>>>>>> would therefore design a [functor]-targeted Range builder API to >>>> allow the >>>>>>> user to specify how next values are obtained. Range may not even be >>>> the best >>>>>>> word to describe the behavior we are trying to model here, so >>>> let's be open >>>>>>> to reinterpretation as we proceed. >>>>>> From my perspective, Range + Step = Sequence. >>>>> I'll buy that if noone else objects. :) >>>>> >>>>>> A Range iterator would be >>>>>> useful for implementing mathematical sets. >>>>> e.g. integer range a..b step 3 yields the sequence of integers n >>>>> greater than or equal to a and less than or equal to b where (n - a) % >>>>> 3 == 0 ? Is this useful? >>>>> >>>>> Matt >>>> It would be useful for a mathematician. Another possibility is a Range >>>> of Dates, with a step of one hour, or one day or... >>>> >>>> The Range class could accept an Iterator factory so various steps can be >>>> implemented in client code. >>>> >>>> -Adrian >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
