Well, with that idea, it got me interested in Meiyo. So, now I'm playing around in a DSL branch trying to improve the API. It seems too verbose to me at the moment. :)
On Sat, Nov 5, 2011 at 11:21 AM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hi James! > I like the idea, the concept reminds me how TestNG's DataProvider and > GoogleGuice Providers. > Looking forward to see it in action! > Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Sat, Nov 5, 2011 at 3:48 PM, James Carman <ja...@carmanconsulting.com> > wrote: >> What if we introduce a @Converter annotation and any method that is >> annotated with this annotation is automatically registered as a >> converter? It's similar to what I've done in Metastopheles >> (http://metastopheles.sourceforge.net/). >> >> On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum >> <adrian.c...@sandglass-software.com> wrote: >>> Agreed. Please don't mis-interpret my replies - I'm not trying to "own" the >>> sandbox, I just want everyone to have a chance to play in it. >>> >>> The recent interest in Convert is great - I hope its popularity and >>> usefulness grows. I'm truly looking forward to more people getting involved. >>> >>> The current code base started out as a work I authored for the Apache Open >>> For Business Project (OFBiz). The converter framework was used for OFBiz's >>> scripting language. My initial work was built out and improved upon by an >>> excellent team of developers. When the converter framework was fairly >>> complete, someone suggested that OFBiz "spin off" the converter framework to >>> a separate library - so I brought it here to Commons. >>> >>> The code you see today is currently being used in an enterprise-class open >>> source ERP application. It is scalable and thread-safe. >>> >>> Commons Convert has not been "fed back" to the OFBiz project yet because it >>> is still in the sandbox. Until a decent sized community grows around it, the >>> OFBiz community will not be willing to switch over to it. I hope to see that >>> switch happen someday. >>> >>> -Adrian >>> >>> On 11/4/2011 11:33 AM, James Carman wrote: >>>> >>>> A branch would work just fine for that situation. Also, let's keep in mind >>>> that this component is in the sandbox >>>> On Nov 4, 2011 7:28 AM, "Adrian Crum"<adrian.c...@sandglass-software.com> >>>> wrote: >>>> >>>>> Not so that someone else can commit them, so that others can review them >>>>> and comment on them. >>>>> >>>>> -Adrian >>>>> >>>>> On 11/4/2011 11:25 AM, James Carman wrote: >>>>> >>>>>> If need be, I would just create a branch for my work. It would be silly >>>>>> for me to submit patches so that someone else would commit them >>>>>> On Nov 4, 2011 7:20 AM, "Adrian Crum"<adrian.crum@sandglass-** >>>>>> software.com<adrian.c...@sandglass-software.com>> >>>>>> wrote: >>>>>> >>>>>> From my perspective, it would be preferable to keep the community >>>>>>> >>>>>>> involved >>>>>>> in the design decisions. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 11/4/2011 11:15 AM, James Carman wrote: >>>>>>> >>>>>>> I don't have to submit a patch. I am a commons committer >>>>>>>> >>>>>>>> On Nov 4, 2011 5:55 AM, "Adrian Crum"<adrian.crum@sandglass-** >>>>>>>> >>>>>>>> software.com<adrian.crum@**sandglass-software.com<adrian.c...@sandglass-software.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> The source and target classes are used by the Converter.canConvert >>>>>>>> >>>>>>>>> method. >>>>>>>>> The Converter.canConvert method is used by the Converter factory to >>>>>>>>> find >>>>>>>>> the correct converter. The reason parameterized types are not used in >>>>>>>>> this >>>>>>>>> scenario is so you can create converters that handle entire class >>>>>>>>> hierarchies. If you can think of a way to replace the Class >>>>>>>>> references >>>>>>>>> with >>>>>>>>> parameters, that would be great. Submit a patch and I will look it >>>>>>>>> over. >>>>>>>>> >>>>>>>>> You could submit a patch for your partially-completed ConverterChain >>>>>>>>> class >>>>>>>>> and maybe someone else will complete it. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/4/2011 2:19 AM, James Carman wrote: >>>>>>>>> >>>>>>>>> I was taking a look at the [convert] component because I have done >>>>>>>>> >>>>>>>>>> some work lately on some handy conversion classes. I'm struggling >>>>>>>>>> to >>>>>>>>>> understand why you'd need the getSourceClass() and getTargetClass() >>>>>>>>>> methods if you're using generics. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, I've got a class that looks like this: >>>>>>>>>> >>>>>>>>>> public class ConverterChain<S,T> implements Converter<S,T> >>>>>>>>>> { >>>>>>>>>> public static<S> ConverterChain<S,S> from(Class<S> >>>>>>>>>> sourceType); >>>>>>>>>> public<N> ConverterChain<S,N> append(Converter<T,N> >>>>>>>>>> converter); >>>>>>>>>> ... >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> I'd like to contribute it, but in my library, I don't have all of >>>>>>>>>> those references to the class objects (source/target). I might >>>>>>>>>> check >>>>>>>>>> it in without the source/target stuff implemented. >>>>>>>>>> >>>>>>>>>> ------------------------------******--------------------------**--** >>>>>>>>>> --**--------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org< >>>>>>>>>> http://apache.org**> >>>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org>< >>>>>>>>>> >>>>>>>>>> dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------******--------------------------**--** >>>>>>>>>> >>>>>>>>> --**--------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org< >>>>>>>>> http://apache.org**> >>>>>>>>> <dev-unsubscribe@**commons.**apache.org<http://commons.apache.org>< >>>>>>>>> >>>>>>>>> dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------****----------------------------** >>>>>>> >>>>>>> --**--------- >>>>>>> To unsubscribe, e-mail: >>>>>>> dev-unsubscribe@commons.**apac**he.org<http://apache.org> >>>>>>> >>>>>>> <dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>> ------------------------------**------------------------------**--------- >>>>> To unsubscribe, e-mail: >>>>> dev-unsubscribe@commons.**apache.org<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 >> >> > > --------------------------------------------------------------------- > 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
