Hi Matt,
> I think we might do better to handle both tasks by designing a generic
> Range builder API, and removing the existing Range classes. This way
> either type of bounding could be requested by the user at his
> convenience.
Great idea Matt. Should we file an issue in JIRA for this?
> Thanks for the publicity (though technically the [functor] component
> is Apache *Commons* functor ;) )!
Thanks! Updated. :)
> Hmm... *which* result is always false? :/
Sorry, I didn't make myself clear here. And actually, the issue is not that the
result is always false, but that IntegerRange .isStopped() and .stop() methods
are defined in the parent class, BaseGenerator. This way, the following code
keeps executing, even after you have called stop() method.
IntegerRange range = new IntegerRange(0, 11);
for(Integer value : range.toCollection()) {
range.stop();
System.out.println(value);
}
However, I believe we should follow your suggestion and work designing a
generic Range builder API. Furthermore, Commons Lang3 has some classes for
ranges in the trunk too (not sure if all of them were released in 3.1).
org.apache.commons.lang3.Range
org.apache.commons.lang3.CharRange
If I understood correctly, the CharSet will depend on Range to generate
CharRange's (see LANG-689 and LANG-670), and the CharRange has a CharIterator.
Looks like maybe we could create Ranges in commons-lang for Integer, Long,
Float and Double, and remove LongRange and IntegerRange from functor. Just food
for thought :)
> I'm not sure we're thinking the exact same thing here, but I do like
> the idea of moving the stop behavior to a custom Generator wrapper
> class. Anything we can do to simplify the Generator API is at least
> up for discussion. It's probably one of the least-understood APIs, in
> all honesty--you must remember that the original developers have long
> since disappeared from the Commons community. If you come across any
> good FP resources showing you the precedent for [functor]'s generator
> APIs I'd be glad for more information.
I will look for FP resources to see if there is anything that could give us
more understanding on the Generator API. This could be useful as documentation
in the project website too.
> Thanks for your ongoing interest,
> Matt
Thank you Matt!
All the best,
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
----- Mensagem original -----
> De: Matt Benson <gudnabr...@gmail.com>
> Para: Commons Developers List <dev@commons.apache.org>; Bruno P. Kinoshita
> <brunodepau...@yahoo.com.br>
> Cc:
> Enviadas: Segunda-feira, 23 de Janeiro de 2012 14:21
> Assunto: Re: [functor] CharacterRange, FloatRange, DoubleRange and
> open/closed intervals
>
> Hi, Bruno; my thoughts inline...
>
> On Sun, Jan 22, 2012 at 6:15 PM, Bruno P. Kinoshita
> <brunodepau...@yahoo.com.br> wrote:
>> Hi all,
>>
>> In functor, there are two ranges available: IntegerRange and LongRange.
> Both use a closed open interval, i.e., the low limit is included in the
> range,
> while the high limit is not.
>>
>> In Perl, we can create a range of numbers too, using the range operator
> (..). Something like 0..10. What produces a closed interval (both 0 and 10
> are
> included). And in Perl, we can create a range of chars too. Like an alphabet,
> a..z. Again, a closed interval.
>>
>> With the current implementation of Ranges in functor, if I want a closed
> interval from 0 to 10, I have to create the following code (limited by 0 and
> 11), that produces a closed/open interval.
>>
>> IntegerRange range = newIntegerRange(0, 11);
>>
>>
>> Now, if I create a CharacterRange, the implementation would have to use a
> closed interval (otherwise z would never be included).
>>
>> CharacterRange range = newCharacterRange('a', 'z');
>>
>>
>> IMHO, we could change the current implementation, before the first release,
> to use a closed interval. It means that it would always include the low and
> high
> limits. This way, both an IntegerRange and a CharacterRange, would have the
> same
> behavior, respecting the Liskov Principle of Substitution. What do you think?
> If
> that sounds reasonable, I could file an issue for the change of behavior in
> JIRA, and another JIRA with an CharacterRange plus tests, and an example for
> the
> web site.
>>
>> Another thing, I have to use float intervals for fuzzy membership functions
> in a project. As I am already using functor there, I thought I could create a
> FloatRange and a DoubleRange for functor. What do you think? If this sounds
> good
> too, I will file an issue in JIRA for this too, with tests and examples for
> the
> web site.
>>
>
> I think we might do better to handle both tasks by designing a generic
> Range builder API, and removing the existing Range classes. This way
> either type of bounding could be requested by the user at his
> convenience.
>
>>
>> I wrote a blog entry to organize my findings while I compared functor
> ranges with other API's and programming languages, maybe someone will find
> it interesting
> - http://www.kinoshita.eti.br/2012/01/22/ranges-in-apache-functor/
>
> Thanks for the publicity (though technically the [functor] component
> is Apache *Commons* functor ;) )!
>
>>
>> There are other points in Integer and Long ranges that I found confusing.
> Like, if you call isStopped() before, during the iteration or after you
> iterated
> over the elements, the result is always false. Not sure if this is the right
> behavior for it.
>
> Hmm... *which* result is always false? :/
>
>> Perhaps this method could be moved from Generator to a StoppableGenerator
> interface, that WhileGenerator, GenerateUntil and others would implement
> (maybe
> even the IntegerRange, or a StoppableIntegerRange. Try creating a
> IntegerRange
> from 0 to Integer.MAX_VALUE and print the values with a UnaryProcedure...
> that
> may take some time :)
>
> I'm not sure we're thinking the exact same thing here, but I do like
> the idea of moving the stop behavior to a custom Generator wrapper
> class. Anything we can do to simplify the Generator API is at least
> up for discussion. It's probably one of the least-understood APIs, in
> all honesty--you must remember that the original developers have long
> since disappeared from the Commons community. If you come across any
> good FP resources showing you the precedent for [functor]'s generator
> APIs I'd be glad for more information.
>
> Thanks for your ongoing interest,
> Matt
>
>>
>> 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
