commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
Date Wed, 06 Jun 2012 02:32:02 GMT
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).

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?

Do you think we should keep the naming standard IntegerRange/LongRange, 
or change them to IntegerGenerator/LongGenerator?

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


Mime
View raw message