commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [functor] Method 'XXX' is not designed for extension
Date Mon, 29 Aug 2011 20:38:51 GMT
On Mon, Aug 29, 2011 at 3:17 PM, Simone Tripodi
<simonetripodi@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
> <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
>
>

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


Mime
View raw message