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 Fri, 26 Aug 2011 19:06:49 GMT
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 <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


Mime
View raw message