You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2011/08/23 21:00:44 UTC
[functor] Method 'XXX' is not designed for extension
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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Matt Benson <gu...@gmail.com>.
On Mon, Aug 29, 2011 at 3:17 PM, Simone Tripodi
<si...@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
> <tu...@gmail.com> wrote:
>> Hi,
>>
>> On 26 August 2011 20:06, Simone Tripodi <si...@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 <gu...@gmail.com> wrote:
>>> > On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
>>> > <si...@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
>>> >> <tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Simone Tripodi <si...@apache.org>.
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
<tu...@gmail.com> wrote:
> Hi,
>
> On 26 August 2011 20:06, Simone Tripodi <si...@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 <gu...@gmail.com> wrote:
>> > On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
>> > <si...@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
>> >> <tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Matthew Pocock <tu...@gmail.com>.
Hi,
On 26 August 2011 20:06, Simone Tripodi <si...@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 <gu...@gmail.com> wrote:
> > On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
> > <si...@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
> >> <tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Simone Tripodi <si...@apache.org>.
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 <gu...@gmail.com> wrote:
> On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
> <si...@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
>> <tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Matt Benson <gu...@gmail.com>.
On Wed, Aug 24, 2011 at 3:14 AM, Simone Tripodi
<si...@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
> <tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Simone Tripodi <si...@apache.org>.
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
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
<tu...@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 <si...@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
Re: [functor] Method 'XXX' is not designed for extension
Posted by Matthew Pocock <tu...@gmail.com>.
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 <si...@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