On Mon, Aug 29, 2011 at 3:17 PM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hi Matthew, > DI is indeed a critical mass that today can not be ignored and since > Apache Commons provides by definition common reusable components, > [functor] has to be able as well to be easily adapted in a context > where DI is required. > > There is anyway a non trivial consideration: [functor] is a collection > of classes that represent methods, so I would be really worried if in > my application there could be interceptors able to modify even > [functor] classes behavior!!! > > So that's why I take in consideration more final classes than final > methods, even if at the same time allowing subclasses would allow > users extending the library set in a way I have not envisioned yet... > > More thoughts? What Matt Benson thinks?
Matt Benson is somewhat reluctant to speak off-the-cuff, especially as he doesn't yet know nearly what he should when it comes to e.g. CDI (maybe struberg will grace us with an opinion). However, in my own experience I can't think what use I've made of functors that would have lent itself to dynamic subclassing, etc.; additionally, the interface-based nature of these things is intended to make composition a simple and natural task, hence the various static methods available throughout the [functor] codebase. So extending any functor would usually be as simple as creating a dynamic proxy or what-have-you. >From what I can tell, making functors final *should* be safe in most cases. Matt > Many thanks in advance, have a nice day!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Aug 26, 2011 at 10:09 PM, Matthew Pocock > <turingatemyhams...@gmail.com> wrote: >> Hi, >> >> On 26 August 2011 20:06, Simone Tripodi <simonetrip...@apache.org> wrote: >> >>> Hi Matt, >>> sorry for the late and for (maybe) silly question, but what's your PoV >>> about making classes Vs methods as 'final'? >>> >> >> If I lived in a world without dependency injection, then I'd favour final >> classes where I wanted to prevent sub-classing, and as a fringe benefit, >> give hotspot extra hints that it can safely start inlining things. It's >> possible that there's no sane reason ever to sub-class some of your classes >> and also no sane reason for them to have bits over-ridden by DI. Removing >> final in the future is a safe change with respect to other people's code. >> Adding final is not. >> >> I personally use final methods when classes are designed for extension and >> are a mix of abstract and final methods. The sub-class is meant to fill in >> the missing behaviour but not over-write the skeleton I've already provided. >> >> Matthew >> >> >> >>> Many thanks in advance, have a nice day!!! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Thu, Aug 25, 2011 at 6:11 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> > On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi >>> > <simonetrip...@apache.org> wrote: >>> >> Hi Matthew! >>> >> >>> >> agreed on such 3rd parties integrations you are speaking about, Google >>> >> Guice would suffer the same (I'm not a fan of Spring :P) >>> >> >>> >> Anyway, as you already mentioned, it is a matter of design, IMHO >>> >> subclassing those classes wouldn't have a lot of sense, since they are >>> >> used to implement a kind of "expression language" - I would be scared >>> >> if in my language I could change the semantic of my syntax... >>> >> >>> >> At the same time I wonder if it would make sense intercepting such >>> >> calls... didn't think to any valid example, do you have one? >>> >> >>> >> Since I'm not the original author of [functor] and I'm just providing >>> >> help to get it in a state to be released, better if more people are >>> >> involved before doing any action :P >>> > >>> > Disclaimer: I am also not the original author, nor am I any master of >>> > FP... on the one hand, many of the complete >>> > algorithm/comparator/composite implementations provided by [functor] >>> > could probably be sensibly made final. On the other hand, applying >>> > this check to #equals(), #hashCode(), etc., seems pretty stupid. >>> > Maybe we should just turn it off. >>> > >>> > Matt >>> > >>> >> >>> >> Thanks for your feedbacks, have a nice day!!! >>> >> All the best, >>> >> Simo >>> >> >>> >> http://people.apache.org/~simonetripodi/ >>> >> http://www.99soft.org/ >>> >> >>> >> >>> >> >>> >> On Wed, Aug 24, 2011 at 12:25 AM, Matthew Pocock >>> >> <turingatemyhams...@gmail.com> wrote: >>> >>> Final classes don't always play well with things like aspects and >>> dependency >>> >>> injection and other things that mangle bytecode or dynamically >>> introduce >>> >>> subclasses/proxies (I'm thinking SPRING). Perhaps this is not an issue >>> here. >>> >>> >>> >>> Should these classes be final? Taking the example of FoldLeft - are >>> their >>> >>> circumstances where it would make sense to sub-class FoldLeft? Can it >>> even >>> >>> be subclassed in a way that would produce something that behaved as a >>> >>> FoldLeft but over-wrote these flagged methods? >>> >>> >>> >>> Matthew >>> >>> >>> >>> On 23 August 2011 20:00, Simone Tripodi <simonetrip...@apache.org> >>> wrote: >>> >>> >>> >>>> Hi all guys, >>> >>>> in [functor] component there are several classes with checkstyle >>> >>>> errors[1] of the type >>> >>>> >>> >>>> Method 'XXXX' is not designed for extension - needs to be >>> >>>> abstract, final or empty. >>> >>>> >>> >>>> My opinion is that such classes should be final - but what someone >>> >>>> else thinks about it? >>> >>>> >>> >>>> TIA, all the best!!! >>> >>>> Simo >>> >>>> >>> >>>> [1] http://commons.apache.org/sandbox/functor/checkstyle.html >>> >>>> >>> >>>> http://people.apache.org/~simonetripodi/ >>> >>>> http://www.99soft.org/ >>> >>>> >>> >>>> --------------------------------------------------------------------- >>> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr Matthew Pocock >>> >>> Visitor, School of Computing Science, Newcastle University >>> >>> mailto: turingatemyhams...@gmail.com >>> >>> gchat: turingatemyhams...@gmail.com >>> >>> msn: matthew_poc...@yahoo.co.uk >>> >>> irc.freenode.net: drdozer >>> >>> tel: (0191) 2566550 >>> >>> mob: +447535664143 >>> >>> >>> >> >>> >> --------------------------------------------------------------------- >>> >> 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 >>> >>> >> >> >> -- >> Dr Matthew Pocock >> Visitor, School of Computing Science, Newcastle University >> mailto: turingatemyhams...@gmail.com >> gchat: turingatemyhams...@gmail.com >> msn: matthew_poc...@yahoo.co.uk >> irc.freenode.net: drdozer >> tel: (0191) 2566550 >> mob: +447535664143 >> > > --------------------------------------------------------------------- > 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
