I've sifted through the archives in commons-dev from ~2002 and found some threads that can be useful regarding the Generators API. I will read it again later to see what I can come up with :) Below are the links and with a short description of each one.
--- Proposal of generators in functor (with attachment) http://markmail.org/message/rtnn2xpudw3ygtvr New thread on the same topic http://markmail.org/message/xainvc6dztvozm63 More on Generator and some discussion on the stoppable behavior, as well as some Java code http://markmail.org/message/v6jzq436awjmdmth A message explaining why EachElement wouldn't implement Generator anymore. http://markmail.org/message/njupdn2i42jit6or Set of links to other APIs with functors and other reference/resources, probably used while writing the initial code. http://markmail.org/message/kf7sxy3otspkcesv#query:+page:1+mid:yiysmyaeua6ne4od+state:results --- Hope that helps. Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com ----- Mensagem original ----- > De: Matt Benson <gudnabr...@gmail.com> > Para: Bruno P. Kinoshita <brunodepau...@yahoo.com.br>; dev@commons.apache.org > Cc: > Enviadas: Terça-feira, 24 de Janeiro de 2012 16:58 > Assunto: Re: [functor] CharacterRange, FloatRange, DoubleRange and > open/closed intervals > > On Tue, Jan 24, 2012 at 12:37 PM, Bruno P. Kinoshita > <brunodepau...@yahoo.com.br> wrote: >> 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? > > That would be fine with me; however see my later comments on Ranges > wrt [functor]. > >> >>> 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); >> } > > Hmm... yes, this doesn't use the Generator API as intended. Calling > toCollection() runs the entire generator. In this case, however, > IntegerRange and LongRange are broken in that they never consult > #isStopped() anyway. I am thinking that we may need to redesign the > entire Generator API, or scrap it entirely if we can't make it make > proper sense. > >> >> 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 :) > > IMO the difference between [lang]'s and [functor]'s range concepts is > that those in [lang] are intended to be able to say whether a given > value is in the Range, but, with the exception of CharRange (this > class is not even public), they make no provision for iterating over > members of the range. I would therefore design a [functor]-targeted > Range builder API to allow the user to specify how next values are > obtained. Range may not even be the best word to describe the > behavior we are trying to model here, so let's be open to > reinterpretation as we proceed. > >> >>> 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. > > Supporting stop behavior without having it live in the basic Generator > interface is one reason I suspect it may be necessary to redesign the > Generator API from the ground up. I still think this sounds like the > right approach, however. > >> >> I will look for FP resources to see if there is anything that could give us > more understanding on the Generator API. > > I will do the same. > > Regards, > Matt > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
