Chg 4832 - Generic collections process like arrays do now.

[Paul Hammant-3]

Paired with Pete yesterday, a change to Parameter has allowed  
components to have generic collections as a declared injectable.

We're at a crossroads though, there are three methods in Parameter  
that need to change somehow:

   Object resolveInstance(PicoContainer container, ComponentAdapter  
adapter, Class expectedType  ...etc
   boolean isResolvable(PicoContainer container, ComponentAdapter  
adapter, Class expectedType  ...etc
   void verify(PicoContainer container,  ComponentAdapter adapter,  
Class expectedType  ...etc

We could change the third param to Type from Class

   Object resolveInstance(PicoContainer container, ComponentAdapter  
adapter, Type expectedType  ...etc
   boolean isResolvable(PicoContainer container, ComponentAdapter  
adapter, Type expectedType  ...etc
   void verify(PicoContainer container,  ComponentAdapter adapter,  
Type expectedType  ...etc

Or we could do an overloaded route by having a second set of three and  
use deprecated on the old three.

The current commit has changed two and overloaded one.

My view is that PC and MPC are the interfaces to be more reverent  
about, and that Parameter is more marginal for backwards compatibility.

Thoughts?

Regards,

- Paul


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mauro Talevi]

Paul Hammant wrote:

> Paired with Pete yesterday, a change to Parameter has allowed components
> to have generic collections as a declared injectable.
>
> We're at a crossroads though, there are three methods in Parameter that
> need to change somehow:
>
>   Object resolveInstance(PicoContainer container, ComponentAdapter
> adapter, Class expectedType  ...etc
>   boolean isResolvable(PicoContainer container, ComponentAdapter
> adapter, Class expectedType  ...etc
>   void verify(PicoContainer container,  ComponentAdapter adapter, Class
> expectedType  ...etc
>
> We could change the third param to Type from Class
>
>   Object resolveInstance(PicoContainer container, ComponentAdapter
> adapter, Type expectedType  ...etc
>   boolean isResolvable(PicoContainer container, ComponentAdapter
> adapter, Type expectedType  ...etc
>   void verify(PicoContainer container,  ComponentAdapter adapter, Type
> expectedType  ...etc
>

Type is more generic and makes more sense in JDK1.5+, because it is the
interface that Class implements (so no loss of functionality in
refactor) but also has as subtype ParameterizedType - which allows to
distinguish genericized params, eg
List<Object1> from List<Object2>,


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[peter royal-3]

On Jul 6, 2008, at 2:57 PM, Mauro Talevi wrote:
> Type is more generic and makes more sense in JDK1.5+, because it is  
> the interface that Class implements (so no loss of functionality in  
> refactor) but also has as subtype ParameterizedType - which allows  
> to distinguish genericized params, eg
> List<Object1> from List<Object2>,

yup, that was exactly the goal.. to be able to see a ParameterizedType  
in the CollectionParameter so we can inject List<Foo> just like Foo[]

-pete

--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

[mihobson]

I wouldn't lose too much sleep over changing the signature.  Like you
say, Parameter is quite a low-level interface that not many users will
be implementing.

Whilst you're there, how about removing the raw types from the
interface too?  e.g. ComponentAdapter to ComponentAdapter<?>, Class to
Class<?>

Cheers,

Mark

2008/7/6 Paul Hammant <paul@...>:

> Paired with Pete yesterday, a change to Parameter has allowed components to
> have generic collections as a declared injectable.
>
> We're at a crossroads though, there are three methods in Parameter that need
> to change somehow:
>
>  Object resolveInstance(PicoContainer container, ComponentAdapter adapter,
> Class expectedType  ...etc
>  boolean isResolvable(PicoContainer container, ComponentAdapter adapter,
> Class expectedType  ...etc
>  void verify(PicoContainer container,  ComponentAdapter adapter, Class
> expectedType  ...etc
>
> We could change the third param to Type from Class
>
>  Object resolveInstance(PicoContainer container, ComponentAdapter adapter,
> Type expectedType  ...etc
>  boolean isResolvable(PicoContainer container, ComponentAdapter adapter,
> Type expectedType  ...etc
>  void verify(PicoContainer container,  ComponentAdapter adapter, Type
> expectedType  ...etc
>
> Or we could do an overloaded route by having a second set of three and use
> deprecated on the old three.
>
> The current commit has changed two and overloaded one.
>
> My view is that PC and MPC are the interfaces to be more reverent about, and
> that Parameter is more marginal for backwards compatibility.
>
> Thoughts?
>
> Regards,
>
> - Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible]

Mauro Talevi wrote:

> Paul Hammant wrote:
>> Paired with Pete yesterday, a change to Parameter has allowed
>> components to have generic collections as a declared injectable.
>>
>> We're at a crossroads though, there are three methods in Parameter
>> that need to change somehow:
>>
>>   Object resolveInstance(PicoContainer container, ComponentAdapter
>> adapter, Class expectedType  ...etc
>>   boolean isResolvable(PicoContainer container, ComponentAdapter
>> adapter, Class expectedType  ...etc
>>   void verify(PicoContainer container,  ComponentAdapter adapter,
>> Class expectedType  ...etc
>>
>> We could change the third param to Type from Class
>>
>>   Object resolveInstance(PicoContainer container, ComponentAdapter
>> adapter, Type expectedType  ...etc
>>   boolean isResolvable(PicoContainer container, ComponentAdapter
>> adapter, Type expectedType  ...etc
>>   void verify(PicoContainer container,  ComponentAdapter adapter,
>> Type expectedType  ...etc
>>
>
> Type is more generic and makes more sense in JDK1.5+, because
> it is the
> interface that Class implements (so no loss of functionality in
> refactor) but also has as subtype ParameterizedType - which allows to
> distinguish genericized params, eg
> List<Object1> from List<Object2>,

+1

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email