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
<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
