commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [functor] Method 'XXX' is not designed for extension
Date Mon, 29 Aug 2011 20:17:57 GMT
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?
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
<turingatemyhamster@gmail.com> wrote:
> Hi,
>
> On 26 August 2011 20:06, Simone Tripodi <simonetripodi@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 <gudnabrsam@gmail.com> wrote:
>> > On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
>> > <simonetripodi@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
>> >> <turingatemyhamster@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 <simonetripodi@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-unsubscribe@commons.apache.org
>> >>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Dr Matthew Pocock
>> >>> Visitor, School of Computing Science, Newcastle University
>> >>> mailto: turingatemyhamster@gmail.com
>> >>> gchat: turingatemyhamster@gmail.com
>> >>> msn: matthew_pocock@yahoo.co.uk
>> >>> irc.freenode.net: drdozer
>> >>> tel: (0191) 2566550
>> >>> mob: +447535664143
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhamster@gmail.com
> gchat: turingatemyhamster@gmail.com
> msn: matthew_pocock@yahoo.co.uk
> irc.freenode.net: drdozer
> tel: (0191) 2566550
> mob: +447535664143
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message