Hi Matt, sorry for the late and for (maybe) silly question, but what's your PoV about making classes Vs methods as 'final'? 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
