Details
-
Type:
Wish
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 2.0
-
Fix Version/s: 2.1
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
Original Dev Posting:
In my own work with PicoContainer I have come to hate (well, ok, maybe hate is a strong work but I certainly strongly dislike! 
) the different interfaces between MutablePico and Pico.
There are a couple of primary reasons for me:
1 - There are several API hacks where you have to return mutable picos, but you get passed in a Pico. (This is mainly in Nano)
2 - Since excessive directly referencing Pico is listed as an AntiPattern (which I agree with), I fail to see how providing a read-only interface provides that much additional usefulness. (So far, I have never had the need myself to ever use the read-only interface.)
That said, I can at least see where a read-only container could be useful, so why don't we provide a readOnlyContainer() function similar to Java Collections that would decorate the container and throw an exception if one of the write functions is called... or something like that.
I think this could clean up some of the Nano @todo issues and I would be a VERY happy camper <grin>.
Activity
Originally posted on dev list by Jörg Schaible
With a separate interface you can hide the implementation behind a proxy, with a single interface you need a seal() method, that prevents any further modification of the instance at all.
Maybe we should just look, where we simply cast to MPC and think then about the interface.
Michael Rimov
added a comment - Originally posted on dev list by Jörg Schaible
With a separate interface you can hide the implementation behind a proxy, with a single interface you need a seal() method, that prevents any further modification of the instance at all.
Maybe we should just look, where we simply cast to MPC and think then about the interface. As a compromise, I'm certainly favorable towards the idea of making Nano require MutablePicoContainers and not merging the interface.
-Mike
Michael Rimov
added a comment - As a compromise, I'm certainly favorable towards the idea of making Nano require MutablePicoContainers and not merging the interface.
-Mike Jörg Schaible
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Component/s | PicoContainer (Java) [ 10191 ] | |
| Description |
Original Dev Posting: In my own work with PicoContainer I have come to hate (well, ok, maybe hate is a strong work -- but I certainly strongly dislike! ;) ) the different interfaces between MutablePico and Pico. There are a couple of primary reasons for me: 1 - There are several API hacks where you have to return mutable picos, but you get passed in a Pico. (This is mainly in Nano) 2 - Since excessive directly referencing Pico is listed as an AntiPattern (which I agree with), I fail to see how providing a read-only interface provides that much additional usefulness. (So far, I have never had the need myself to ever use the read-only interface.) That said, I can at least see where a read-only container could be useful, so why don't we provide a readOnlyContainer() function similar to Java Collections that would decorate the container and throw an exception if one of the write functions is called... or something like that. I think this could clean up some of the Nano @todo issues and I would be a VERY happy camper <grin>. |
Original Dev Posting: In my own work with PicoContainer I have come to hate (well, ok, maybe hate is a strong work -- but I certainly strongly dislike! ;) ) the different interfaces between MutablePico and Pico. There are a couple of primary reasons for me: 1 - There are several API hacks where you have to return mutable picos, but you get passed in a Pico. (This is mainly in Nano) 2 - Since excessive directly referencing Pico is listed as an AntiPattern (which I agree with), I fail to see how providing a read-only interface provides that much additional usefulness. (So far, I have never had the need myself to ever use the read-only interface.) That said, I can at least see where a read-only container could be useful, so why don't we provide a readOnlyContainer() function similar to Java Collections that would decorate the container and throw an exception if one of the write functions is called... or something like that. I think this could clean up some of the Nano @todo issues and I would be a VERY happy camper <grin>. |
I think that cleaning up the NanoContainer vs PicoContainer API issues has helped make this more of a moot point.
I'm certainly content with leaving them separate at this point.
Michael Rimov
added a comment - I think that cleaning up the NanoContainer vs PicoContainer API issues has helped make this more of a moot point.
I'm certainly content with leaving them separate at this point. Michael Rimov
made changes -
| Resolution | Won't Fix [ 2 ] | |
| Fix Version/s | 2.1 [ 14250 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
he question you raise is certainly legittimate - in particular wrt which interface is used in Nano.
I agree that in most Nano uses the main interface should be a MPC.
Originally Poisted by Mauro Talevi on list.
That said, I think this can be achieved by simply changing the Nano interfaces to expect MPC as the default interface.
Leaving the PC and MPC interface inheritance model does not really do any harm, does it?
I personally use this sort of design pattern (making mutable interfaces extend immutable ones) quite a lot and find it good (not necessarily for containers which are more prone to be mutable
But certainly it is not the only option and the decoration to make a container read only is another.
We need to have an honest appraisal of what has worked best and least in Pico 1 and build on that for Pico 2.
Don't know what other think, but I would surely warrant a jira issue - if nothing else for folks to comment on.