Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of gudnabrsam@gmail.com
 designates 209.85.160.43 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: <1338872346.30251.YahooMailNeo@web161202.mail.bf1.yahoo.com>
References: <1338872346.30251.YahooMailNeo@web161202.mail.bf1.yahoo.com>
Date: Tue, 5 Jun 2012 10:08:56 -0500
Message-ID: 
 <CAE9L6G30Qa5HUog2Wss5BtmBzR1zYQVOmUrL4=4VQ3TA_9OW5Q@mail.gmail.com>
Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
From: Matt Benson <gudnabrsam@gmail.com>
To: Commons Developers List <dev@commons.apache.org>,
	"Bruno P. Kinoshita" <brunodepaulak@yahoo.com.br>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 [fu=
nctor]. I'd like to hear what others think about what was done before attac=
hing the patch to JIRA:
>
> - Didn't change the Generator interface. Although I commented in the issu=
e about removing the stop() and isStopped() methods and moving to a differe=
nt interface, it would require a major refactoring, as many other generator=
s are built upon this idea.
>
> - Created IntegerGenerator, LongGenerator, FloatGenerator, DoubleGenerato=
r and CharacterGenerator. Didn't implement a DateGenerator as it would requ=
ire more time and a discussion on how to use days, months, years, days of w=
eek, etc.
>
> - Introduced Ranges, with the following initial ranges: IntegerRange, Lon=
gRange, FloatRange, DoubleRange and CharacterRange. This API is quite simil=
ar to other existing APIs, with the difference that you can specify the ste=
p (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 obj=
ects are created only when the generator is executed, calling a procedure. =
Like in python, but instead of retrieving the value with a 'yield' statemen=
t, 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 ra=
nge/generator is a very simple, and there are some operations with double/f=
loat in the ranges and generators. I keep my code mirrored in github too, i=
n case someone prefers reading it there=A0https://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