Am 28.01.2013 um 21:12 schrieb Matt Benson <gudnabr...@gmail.com>:
> On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita <ki...@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 <gudnabr...@gmail.com>
>>> To: Simone Tripodi <simonetrip...@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 <simonetrip...@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 <gudnabr...@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 <
>>>> simonetrip...@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
>>>>>> <brunodepau...@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 <gudnabr...@gmail.com>
>>>>>>>> To: Bruno P. Kinoshita <brunodepau...@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
>>>>>>>> <brunodepau...@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
>>>>>>>>>> <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
>>>>>>>>>> *ha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
