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 04:48:04 GMT
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()).

 > 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


Mime
View raw message