Re: [functor] modularization
great +1 on that - when working towards the first [functor] release, I was worried that if our intention is including [functor] in BVal, I would have brought a lot of unused stuff. count on my support! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jun 13, 2012 at 6:00 PM, Matt Benson gudnabr...@gmail.com wrote: I think it would be useful to extract at least the interfaces to an api module, so that other libraries could depend on [functor] without bringing along everything. Does anyone have any feelings on further subdivisions within the [functor] codebase that might be useful? Matt - 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
Re: [functor] modularization
I like it! Sounds like something we should do with proxy2! :) On Wed, Jun 13, 2012 at 12:00 PM, Matt Benson gudnabr...@gmail.com wrote: I think it would be useful to extract at least the interfaces to an api module, so that other libraries could depend on [functor] without bringing along everything. Does anyone have any feelings on further subdivisions within the [functor] codebase that might be useful? Matt - 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
Re: [functor] modularization
My +1 on this too :-) great idea Matt. Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com From: Matt Benson gudnabr...@gmail.com To: dev@commons.apache.org Sent: Wednesday, 13 June 2012 1:00 PM Subject: [functor] modularization I think it would be useful to extract at least the interfaces to an api module, so that other libraries could depend on [functor] without bringing along everything. Does anyone have any feelings on further subdivisions within the [functor] codebase that might be useful? Matt - 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