commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
Date Wed, 19 Sep 2012 07:12:25 GMT
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
<brunodepaulak@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 <gudnabrsam@gmail.com>
>>To: Bruno P. Kinoshita <brunodepaulak@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
>><brunodepaulak@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
>>>> <brunodepaulak@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
>>>>>> <brunodepaulak@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message