All: I have merged Bruno's work to https://svn.apache.org/repos/asf/commons/proper/functor/branches/FUNCTOR-14-mmbased on functor's multi-module reorg.
Matt On Wed, Sep 19, 2012 at 2:12 AM, Simone Tripodi <simonetrip...@apache.org>wrote: > Olá Bruno, > > excellent work, congrats!! I will have a look tonight (my local TZ) > I'll try to let you know ASAP! > > thanks, all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita > <brunodepau...@yahoo.com.br> wrote: > > Hi all, > > > > me again bringing a new implementation idea for the Generators API > > > > in [functor], and looking forward to some thoughts on this :-) > > > > There is a separate branch for this issue [1], and here's what has been > done. > > > > - Split Generator interface into Generator interface and LoopGenerator > > (abstract class). IMO, this will help in modularization (see this > discussion [2]) > > in the Generators API, as the stop() method and the wrapped generators, > > for instance, had been added because of the generators created for > handling > > execution flow control (e.g.: GenerateWhile, UntilGenerate, etc). > > > > - Moved LoopGenerator and its implementations under the newly created > > org.apache.commons.functor.generator.loop package. > > > > - Moved IntegerRange and LongRange from > org.apache.commons.functor.generator.util to > > the newly created org.apache.commons.functor.generator.range package. > > > > - Created a Range API, with a Range interface, a Ranges helper interface > and > > some implementations (including existing IntegerRange and LongRange, and > new > > ones like DoubleRange, FloatRange and CharacterRange). > > > > - Added steps different than 1 to Ranges (not the generator interface, > as this > > is related only to ranges). > > > > - The Ranges implemented are all Generators too, what is very > convenient, as you > > can use Ranges to both define intervals and/or execute a procedure for > each of its > > elements. > > > > I've wrote a sample code using the existing Generators API [3] and wrote > the > > same code for the new Generators API [4]. The API is compatible, but as > some > > packages changed, you have to update existing code (but as [functor] > hasn't been > > released yet, it shouldn't be a problem I believe :-). Both codes > produce the > > same output too (0 1 2 3 4 5 6 7 8 9 ). > > > > And here's an example [5] of creating Ranges and using them as > Generators. More > > examples can be found in the tests for the Generator and the Range API's. > > > > I've updated the examples page and added tests. I've also updated the > parent > > pom to 26, but as this is not related to the FUNCTOR-14 issue, we can > drop this > > > > part when merging the code. > > > > I'll merge the changes to trunk if everybody thinks this new > implementation is > > better than the current one. > > > > A side note: PHP recently got generators too [6], and an interesting > thing that I noticed in > > their Wiki was the discussion about callback functions. After reading the > > discussion, for me it looks like [functor] generators API is more > similar to > > callback handler. Differently than the Python and PHP implementations > with the > > yield statement. > > > > Thank you in advance! > > > > [1] > https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14 > > [2] http://markmail.org/message/nymsk7l64aj4csxi > > [3] https://gist.github.com/3747204 > > [4] https://gist.github.com/3747207 > > [5] https://gist.github.com/3747224 > > [5] https://wiki.php.net/rfc/generators > > > > Bruno P. Kinoshita > > http://kinoshita.eti.br > > http://tupilabs.com > > > >>________________________________ > >> From: Matt Benson <gudnabr...@gmail.com> > >>To: Bruno P. Kinoshita <brunodepau...@yahoo.com.br> > >>Cc: Commons Developers List <dev@commons.apache.org> > >>Sent: Wednesday, 6 June 2012 9:56 AM > >>Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges > >> > >>On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita > >><brunodepau...@yahoo.com.br> wrote: > >>> Hi Matt, > >>> > >>> > >>>> Would there be a type of Range that could not be turned into a > >>>> Generator given a compatible Step parameter? If not, we could define: > >>>> > >>>> interface Range<T, S> { > >>>> ... > >>>> Generator<T> toGenerator(S step); > >>>> } > >>>> > >>>> This way, Range itself does not contain a step, but still maintains > >>>> control over how a step is used to create a generator. > >>> > >>> I can't think of any type that could not be turned into a generator > given > >>> the step parameter. But if a range has no step, I think we would have > to > >>> remove the isEmpty(), contains(), containsAll() methods from range > >>> implementations, as using steps higher than 1, we need to use the step > value > >>> to check if a range is empty or contains a certain element (e.g.: > integer > >>> range (1, 2], step 3, check if contains(2) or isEmpty()). > >>> > >> > >>My thought was that by decoupling a Range from a step, you use only > >>the bound types/values to determine inclusion of a given value. If a > >>Generator is created from (1, 2] with step 3, then that Generator will > >>only return 1, but that doesn't reflect on the Range, IMO. > >> > >>Matt > >> > >>> > >>>> Either way, I like the notion that a Range is its own type that just > >>>> *happens* to either provide access to, or an implementation of, > >>>> Generator. > >>> > >>> +1, let it provide access or be an implementation of Generator. In > case we > >>> do the latter case, I believe isEmpty(), contains() and other methods > using > >>> the step value would be doable. > >>> > >>> Regards, > >>> > >>> > >>> Bruno P. Kinoshita > >>> http://www.kinoshita.eti.br > >>> http://www.tupilabs.com > >>> > >>> On 06/05/2012 11:52 PM, Matt Benson wrote: > >>>> > >>>> Hi, Bruno. Likewise, answers inline: > >>>> > >>>> On Tue, Jun 5, 2012 at 9:32 PM, Bruno P. Kinoshita > >>>> <brunodepau...@yahoo.com.br> wrote: > >>>>> > >>>>> Hi Matt! > >>>>> > >>>>> Thanks for your response! Answers added inline. > >>>>> > >>>>> > >>>>>> 1. Why are a Range's type and step-type potentially different > >>>>>> (different type variables, etc.)? > >>>>> > >>>>> > >>>>> When I started writing this patch, the range's type and step-type > were > >>>>> the > >>>>> same (i.e. the interface had only one generics type,<T>), but then I > >>>>> created the CharacterRange and it didn't work because its range type > is > >>>>> Character and its step-type is Integer (same would happen for a > >>>>> DateRange). > >>>> > >>>> > >>>> I see; good point. > >>>> > >>>>> > >>>>> What do you think? Maybe with some generics magic or with a different > >>>>> approach we could remove the step-type? (I would be +1 for this) > >>>>> > >>>>> > >>>>>> 2. Why, if it is a Generator's responsibility to generate items > >>>>>> subsequent to the lower endpoint, is the step part of the range at > >>>>>> all? Based on [1], which definition of "range" are we attempting to > >>>>>> represent? > >>>>> > >>>>> > >>>>> In google guava and java-yield a range is a generator, as it was in > >>>>> [functor] too (this patch removes the old IntegerRange, a generator > of > >>>>> Integers). > >>>>> > >>>>> [functor] has generators that don't require steps (GenerateWhile, > >>>>> WhileGenerate, UntilGenerate, etc). I think random generators > wouldn't > >>>>> use > >>>>> steps too (e.g.: RandomIntegerGenerator, USPhoneNumberGenerator, > >>>>> UUIDGenerator, PrimeNumberGenerator). > >>>>> > >>>>> The initial idea of the Range interface, was to have similar > behavior as > >>>>> commons-lang's Range [1], plus being able to define steps and have > the > >>>>> actual process (the yield) being executed by an external agent, a > >>>>> generator. > >>>>> In the end, I think the of the Range in my patch would be more like > an > >>>>> Interval [2]?. > >>>>> > >>>>> > >>>>>> The current code seems to implement definition 2 and > >>>>>> *part* of definition 3, deferring the rest to a corresponding > >>>>>> Generator. > >>>>> > >>>>> > >>>>> I couldn't have said it better :-) > >>>>> > >>>>> > >>>>>> Settling the question of whether [functor]'s Range is a > >>>>>> "2-range" or also a "3-range" would seem to dictate our action: do > we > >>>>>> move the step to the generator, or do we make Range calculate each > >>>>>> item (in which case would it be simpler for Range to implement > >>>>>> Generator)? > >>>>> > >>>>> > >>>>> After reading your considerations, I now think that it would be > better to > >>>>> maintain the current approach (Range implements a Generator) and try > to > >>>>> implement generators for double, float and character using the actual > >>>>> interfaces and try to use steps. What do you think? > >>>> > >>>> > >>>> Would there be a type of Range that could not be turned into a > >>>> Generator given a compatible Step parameter? If not, we could define: > >>>> > >>>> interface Range<T, S> { > >>>> ... > >>>> Generator<T> toGenerator(S step); > >>>> } > >>>> > >>>> This way, Range itself does not contain a step, but still maintains > >>>> control over how a step is used to create a generator. > >>>> > >>>>> > >>>>> Do you think we should keep the naming standard > IntegerRange/LongRange, > >>>>> or > >>>>> change them to IntegerGenerator/LongGenerator? > >>>> > >>>> > >>>> Either way, I like the notion that a Range is its own type that just > >>>> *happens* to either provide access to, or an implementation of, > >>>> Generator. > >>>> > >>>> br, > >>>> Matt > >>>> > >>>>> > >>>>> Thank you for reviewing my patch and for the interesting questions! > I'm > >>>>> no > >>>>> FP expert either, feel free to suggest different ideas, no hard > feelings > >>>>> :) > >>>>> > >>>>> [1] > >>>>> > >>>>> > http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Range.java?view=markup > >>>>> [2] http://en.wikipedia.org/wiki/Interval_(mathematics) > >>>>> > >>>>> Bruno P. Kinoshita > >>>>> http://www.kinoshita.eti.br > >>>>> http://www.tupilabs.com > >>>>> > >>>>> > >>>>> On 06/05/2012 12:08 PM, Matt Benson wrote: > >>>>>> > >>>>>> > >>>>>> Hi, Bruno! > >>>>>> > >>>>>> I have some questions: > >>>>>> > >>>>>> 1. Why are a Range's type and step-type potentially different > >>>>>> (different type variables, etc.)? > >>>>>> 2. Why, if it is a Generator's responsibility to generate items > >>>>>> subsequent to the lower endpoint, is the step part of the range at > >>>>>> all? Based on [1], which definition of "range" are we attempting to > >>>>>> represent? The current code seems to implement definition 2 and > >>>>>> *part* of definition 3, deferring the rest to a corresponding > >>>>>> Generator. Settling the question of whether [functor]'s Range is a > >>>>>> "2-range" or also a "3-range" would seem to dictate our action: do > we > >>>>>> move the step to the generator, or do we make Range calculate each > >>>>>> item (in which case would it be simpler for Range to implement > >>>>>> Generator)? > >>>>>> > >>>>>> I am by no means an FP or any other type of expert, so feel free to > >>>>>> show me why I'm wrong on a given point! > >>>>>> > >>>>>> br, > >>>>>> Matt > >>>>>> > >>>>>> [1] http://en.wikipedia.org/wiki/Range_(computer_science) > >>>>>> > >>>>>> On Mon, Jun 4, 2012 at 11:59 PM, Bruno P. Kinoshita > >>>>>> <brunodepau...@yahoo.com.br> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I've finished a patch for FUNCTOR-14, regarding the Generators API > in > >>>>>>> [functor]. I'd like to hear what others think about what was done > >>>>>>> before > >>>>>>> attaching the patch to JIRA: > >>>>>>> > >>>>>>> - Didn't change the Generator interface. Although I commented in > the > >>>>>>> issue about removing the stop() and isStopped() methods and moving > to a > >>>>>>> different interface, it would require a major refactoring, as many > >>>>>>> other > >>>>>>> generators are built upon this idea. > >>>>>>> > >>>>>>> - Created IntegerGenerator, LongGenerator, FloatGenerator, > >>>>>>> DoubleGenerator and CharacterGenerator. Didn't implement a > >>>>>>> DateGenerator as > >>>>>>> it would require more time and a discussion on how to use days, > months, > >>>>>>> years, days of week, etc. > >>>>>>> > >>>>>>> - Introduced Ranges, with the following initial ranges: > IntegerRange, > >>>>>>> LongRange, FloatRange, DoubleRange and CharacterRange. This API is > >>>>>>> quite > >>>>>>> similar to other existing APIs, with the difference that you can > >>>>>>> specify the > >>>>>>> step (like ranges in Matlab) > >>>>>>> > >>>>>>> - The generators that use numbers (there are many other generators, > >>>>>>> like > >>>>>>> GenerateWhile, GenerateUntil, etc) use ranges to create the > series. The > >>>>>>> objects are created only when the generator is executed, calling a > >>>>>>> procedure. Like in python, but instead of retrieving the value > with a > >>>>>>> 'yield' statement, we give a procedure to be executed using the > value > >>>>>>> created. > >>>>>>> > >>>>>>> - Included tests to cover the changes. > >>>>>>> > >>>>>>> - Updated web site examples. > >>>>>>> > >>>>>>> All the tests passed, no checkstyle/pmd/findbugs errors. The > character > >>>>>>> range/generator is a very simple, and there are some operations > with > >>>>>>> double/float in the ranges and generators. I keep my code mirrored > in > >>>>>>> github > >>>>>>> too, in case someone prefers reading it there > >>>>>>> https://github.com/kinow/functor. > >>>>>>> > >>>>>>> Let me know what you think about it :-) > >>>>>>> > >>>>>>> Thank you in advance! > >>>>>>> > >>>>>>> Bruno P. Kinoshita > >>>>>>> http://kinoshita.eti.br > >>>>>>> http://tupilabs.com > >>>>>>> > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
