commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
Date Mon, 28 Jan 2013 20:30:12 GMT


Am 28.01.2013 um 21:12 schrieb Matt Benson <gudnabrsam@gmail.com>:

> On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita <kinow@apache.org>wrote:
> 
>> Hi Matt
>> 
>>> As for the modularization, I went ahead and did this in the trunk.  On
>>> the overall I think Bruno's work is proceeding in a good direction, so I
>>> agree that it should be merged back to trunk when ready.
>> 
>> Thanks! I'll sync the repos here at office in the next hours. Regarding
>> the other refactorings.
>> 
>>> - LoopingGenerator's wrapping constructor should only accept other looping
>>> generators; otherwise, the objects will do things users probably don't
>>> expect.
>> 
>> +1 it makes sense indeed
> 
> I've actually realized now that it should not be necessary for the
> generator wrapped by one of these to implement
> whatever-the-name-of-the-abstract-class is.  I am now thinking
> PredicatedGenerator with a Behavior enum { TEST_BEFORE, TEST_AFTER }.
> 
> Matt
> 
> 
>> 
>>> - LoopingGenerator should be renamed to something that relates to its
>>> "stoppable" quality. StoppableGenerator?  InterruptibleGenerator?
>> 
>> I first named it StoppableGenerator, then changed to LoopGenerator since
>> it was being used in classes that reproduced while, dowhile, until, etc.
>> 
>> StoppableGenerator makes it very clear the "stoppable" behaviour of the
>> generators, but I'm okay with any name. My main concern was having the
>> stop() method in the Generator interface :)

Hi,

without knowing the code base in detail I would not recommend calling it an InterruptibleGenerator,
because this could cause confusion with java's thread interruption features.

Benedikt

>> 
>>> - Several of the generator implementations, e.g. UntilGenerate, don't seem
>>> to behave consistently with their description.
>> 
>> I'll take a look on the generators again, but I remember it took me some
>> time to get used to the Until, DoWhile, UntilGenerate and other generators.
>> 
>>> - I still feel Range should be decoupled from Generator.  I think it would
>>> be better to join a Range<T> with a UnaryFunction<T, T> to create
the step
>>> needed to go from Range to Generator.  This would be more flexible than a
>>> simple addition-based step anyway.
>> 
>> +1 sounds great Matt. IIUC, this way if I wanted something like a
>> PrimeNumberGenerator, I could pass a PrimeNumberFunction. FWIW, there is a
>> Range in the lambda project too, probably it is worth taking a look on
>> their API too.
>> 
>> Thanks!
>> 
>> Bruno P. Kinoshita
>> http://kinoshita.eti.br
>> http://tupilabs.com
>> 
>> 
>>> ________________________________
>>> From: Matt Benson <gudnabrsam@gmail.com>
>>> To: Simone Tripodi <simonetripodi@apache.org>
>>> Cc: Commons Developers List <dev@commons.apache.org>
>>> Sent: Monday, January 28, 2013 2:00 PM
>>> Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
>>> 
>>> Hi Simo,
>>> As for the modularization, I went ahead and did this in the trunk.  On
>>> the overall I think Bruno's work is proceeding in a good direction, so I
>>> agree that it should be merged back to trunk when ready.  I have some more
>>> refactorings i am interested to try out on this, or another, branch.
>> These
>>> are all, of course, my opinion:
>>> 
>>> - LoopingGenerator's wrapping constructor should only accept other looping
>>> generators; otherwise, the objects will do things users probably don't
>>> expect.
>>> - LoopingGenerator should be renamed to something that relates to its
>>> "stoppable" quality. StoppableGenerator?  InterruptibleGenerator?
>>> - Several of the generator implementations, e.g. UntilGenerate, don't seem
>>> to behave consistently with their description.
>>> - I still feel Range should be decoupled from Generator.  I think it would
>>> be better to join a Range<T> with a UnaryFunction<T, T> to create
the step
>>> needed to go from Range to Generator.  This would be more flexible than a
>>> simple addition-based step anyway.
>>> 
>>> Does anyone object to any of these changes?
>>> 
>>> Matt
>>> 
>>> 
>>> On Mon, Jan 28, 2013 at 2:46 AM, Simone Tripodi <simonetripodi@apache.org
>>> wrote:
>>> 
>>>> Hi Matt,
>>>> 
>>>> I had a quick look at your branch and I honestly think it is a very
>>>> good work, maybe we could insert even more modules granularization,
>>>> but IMHO it worths to merge it in the main branch.
>>>> Do you see any blocker?
>>>> 
>>>> Best and thanks!
>>>> -Simo
>>>> 
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>> 
>>>> 
>>>> On Sun, Jan 27, 2013 at 6:39 PM, Matt Benson <gudnabrsam@gmail.com>
>> wrote:
>>>>> All:  I have merged Bruno's work to
>> https://svn.apache.org/repos/asf/commons/proper/functor/branches/FUNCTOR-14-mmbased
>>>>> on functor's multi-module reorg.
>>>>> 
>>>>> Matt
>>>>> 
>>>>> 
>>>>> On Wed, Sep 19, 2012 at 2:12 AM, Simone Tripodi <
>>>> simonetripodi@apache.org>wrote:
>>>>> 
>>>>>> Olá Bruno,
>>>>>> 
>>>>>> excellent work, congrats!! I will have a look tonight (my local TZ)
>>>>>> I'll try to let you know ASAP!
>>>>>> 
>>>>>> thanks, all the best!
>>>>>> -Simo
>>>>>> 
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>> 
>>>>>> 
>>>>>> On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita
>>>>>> <brunodepaulak@yahoo.com.br> wrote:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> me again bringing a new implementation idea for the Generators
API
>>>>>>> 
>>>>>>> in [functor], and looking forward to some thoughts on this :-)
>>>>>>> 
>>>>>>> There is a separate branch for this issue [1], and here's what
has
>>>> been
>>>>>> done.
>>>>>>> 
>>>>>>> - Split Generator interface into Generator interface and
>> LoopGenerator
>>>>>>> (abstract class). IMO, this will help in modularization (see
this
>>>>>> discussion [2])
>>>>>>> in the Generators API, as the stop() method and the wrapped
>>>> generators,
>>>>>>> for instance, had been added because of the generators created
for
>>>>>> handling
>>>>>>> execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
>>>>>>> 
>>>>>>> - Moved LoopGenerator and its implementations under the newly
>> created
>>>>>>> org.apache.commons.functor.generator.loop package.
>>>>>>> 
>>>>>>> - Moved IntegerRange and LongRange from
>>>>>> org.apache.commons.functor.generator.util to
>>>>>>> the newly created org.apache.commons.functor.generator.range
>> package.
>>>>>>> 
>>>>>>> - Created a Range API, with a Range interface, a Ranges helper
>>>> interface
>>>>>> and
>>>>>>> some implementations (including existing IntegerRange and
>> LongRange,
>>>> and
>>>>>> new
>>>>>>> ones like DoubleRange, FloatRange and CharacterRange).
>>>>>>> 
>>>>>>> - Added steps different than 1 to Ranges (not the generator
>> interface,
>>>>>> as this
>>>>>>> is related only to ranges).
>>>>>>> 
>>>>>>> - The Ranges implemented are all Generators too, what is very
>>>>>> convenient, as you
>>>>>>> can use Ranges to both define intervals and/or execute a procedure
>> for
>>>>>> each of its
>>>>>>> elements.
>>>>>>> 
>>>>>>> I've wrote a sample code using the existing Generators API [3]
and
>>>> wrote
>>>>>> the
>>>>>>> same code for the new Generators API [4]. The API is compatible,
>> but
>>>> as
>>>>>> some
>>>>>>> packages changed, you have to update existing code (but as
>> [functor]
>>>>>> hasn't been
>>>>>>> released yet, it shouldn't be a problem I believe :-). Both codes
>>>>>> produce the
>>>>>>> same output too (0 1 2 3 4 5 6 7 8 9 ).
>>>>>>> 
>>>>>>> And here's an example [5] of creating Ranges and using them as
>>>>>> Generators. More
>>>>>>> examples can be found in the tests for the Generator and the
Range
>>>> API's.
>>>>>>> 
>>>>>>> I've updated the examples page and added tests. I've also updated
>> the
>>>>>> parent
>>>>>>> pom to 26, but as this is not related to the FUNCTOR-14 issue,
we
>> can
>>>>>> drop this
>>>>>>> 
>>>>>>> part when merging the code.
>>>>>>> 
>>>>>>> I'll merge the changes to trunk if everybody thinks this new
>>>>>> implementation is
>>>>>>> better than the current one.
>>>>>>> 
>>>>>>> A side note: PHP recently got generators too [6], and an
>> interesting
>>>>>> thing that I noticed in
>>>>>>> their Wiki was the discussion about callback functions. After
>> reading
>>>> the
>>>>>>> discussion, for me it looks like [functor] generators API is
more
>>>>>> similar to
>>>>>>> callback handler. Differently than the Python and PHP
>> implementations
>>>>>> with the
>>>>>>> yield statement.
>>>>>>> 
>>>>>>> Thank you in advance!
>>>>>>> 
>>>>>>> [1]
>> https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
>>>>>>> [2] http://markmail.org/message/nymsk7l64aj4csxi
>>>>>>> [3] https://gist.github.com/3747204
>>>>>>> [4] https://gist.github.com/3747207
>>>>>>> [5] https://gist.github.com/3747224
>>>>>>> [5] https://wiki.php.net/rfc/generators
>>>>>>> 
>>>>>>> Bruno P. Kinoshita
>>>>>>> http://kinoshita.eti.br
>>>>>>> http://tupilabs.com
>>>>>>> 
>>>>>>>> ________________________________
>>>>>>>> From: Matt Benson <gudnabrsam@gmail.com>
>>>>>>>> To: Bruno P. Kinoshita <brunodepaulak@yahoo.com.br>
>>>>>>>> Cc: Commons Developers List <dev@commons.apache.org>
>>>>>>>> Sent: Wednesday, 6 June 2012 9:56 AM
>>>>>>>> Subject: Re: [functor] Patch for FUNCTOR-14, new Generators
and
>> Ranges
>>>>>>>> 
>>>>>>>> On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita
>>>>>>>> <brunodepaulak@yahoo.com.br> wrote:
>>>>>>>>> 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()).
>>>>>>>> 
>>>>>>>> My thought was that by decoupling a Range from a step, you
use only
>>>>>>>> the bound types/values to determine inclusion of a given
value.
>> If a
>>>>>>>> Generator is created from (1, 2] with step 3, then that Generator
>> will
>>>>>>>> only return 1, but that doesn't reflect on the Range, IMO.
>>>>>>>> 
>>>>>>>> Matt
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> <brunodepaulak@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
>>>>>>>>>> *ha

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message