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
