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