[chain][v2] clever context

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[chain][v2] clever context

Simone Tripodi-2
Hi all guys,
I think that generics could help us on improving the Context class;
I'm not particularly happy having it extending Map - it is needed
anyway for backward compatibility - but it is clear that Context is a
place where storing/retrieving objects identified by a key.
I propose adding two helper methods

    /** @since 2.0 */
    <T> T retrieve( String key );

    /** @since 2.0 */
    <T> void store( String key, T object );

that would help users avoid the redundant code of type cast/checking
when assignments are already known (it throws a ClassCastException if
types are not assignable).
At the same time, old pattern is supported, users can choose their
preferred way to go, depending on their needs.
WDYT?
Many thanks in advance, all the best!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

James Carman
Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
and it was shot down
(http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
 Good luck with that.  It wasn't worth my time to continue to argue
about it anymore, so I reverted it.

On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:

> Hi all guys,
> I think that generics could help us on improving the Context class;
> I'm not particularly happy having it extending Map - it is needed
> anyway for backward compatibility - but it is clear that Context is a
> place where storing/retrieving objects identified by a key.
> I propose adding two helper methods
>
>    /** @since 2.0 */
>    <T> T retrieve( String key );
>
>    /** @since 2.0 */
>    <T> void store( String key, T object );
>
> that would help users avoid the redundant code of type cast/checking
> when assignments are already known (it throws a ClassCastException if
> types are not assignable).
> At the same time, old pattern is supported, users can choose their
> preferred way to go, depending on their needs.
> WDYT?
> Many thanks in advance, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Matt Benson-2
Obviously I've suggested this "auto-cast" or
whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
use.

Matt

On Sun, Sep 4, 2011 at 7:39 AM, James Carman <[hidden email]> wrote:

> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>  Good luck with that.  It wasn't worth my time to continue to argue
> about it anymore, so I reverted it.
>
> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>>    /** @since 2.0 */
>>    <T> T retrieve( String key );
>>
>>    /** @since 2.0 */
>>    <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>> Many thanks in advance, all the best!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Matt!
indeed, that's thanks to you that the Digester3 has this feature!!! :)
Thanks for the feedback!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 6:13 PM, Matt Benson <[hidden email]> wrote:

> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
> use.
>
> Matt
>
> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <[hidden email]> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>>  Good luck with that.  It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>>    /** @since 2.0 */
>>>    <T> T retrieve( String key );
>>>
>>>    /** @since 2.0 */
>>>    <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, all the best!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
In reply to this post by James Carman
Hi James!
I remember that thread :(
Hope you have a nice WE, all the best!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 2:39 PM, James Carman <[hidden email]> wrote:

> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>  Good luck with that.  It wasn't worth my time to continue to argue
> about it anymore, so I reverted it.
>
> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>>    /** @since 2.0 */
>>    <T> T retrieve( String key );
>>
>>    /** @since 2.0 */
>>    <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>> Many thanks in advance, all the best!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi added that feature, see CHAIN-56 for details.
I'll re-upload the site on my p.a.o home so we can continue discussing
about [chain] potential graduation.
Thanks, all the best!!!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 6:26 PM, Simone Tripodi <[hidden email]> wrote:

> Hi James!
> I remember that thread :(
> Hope you have a nice WE, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Sep 4, 2011 at 2:39 PM, James Carman <[hidden email]> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>>  Good luck with that.  It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>>    /** @since 2.0 */
>>>    <T> T retrieve( String key );
>>>
>>>    /** @since 2.0 */
>>>    <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, all the best!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

James Carman
In reply to this post by Matt Benson-2
To be clear, I am also in favor of this approach.  I don't think we
need to patronize our users by trying to hold their hands.  A
ClassCastException would be a pretty obvious indicator as to what is
going wrong with something like this.

On Sun, Sep 4, 2011 at 12:13 PM, Matt Benson <[hidden email]> wrote:

> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
> use.
>
> Matt
>
> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <[hidden email]> wrote:
>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>> and it was shot down
>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>>  Good luck with that.  It wasn't worth my time to continue to argue
>> about it anymore, so I reverted it.
>>
>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>>> Hi all guys,
>>> I think that generics could help us on improving the Context class;
>>> I'm not particularly happy having it extending Map - it is needed
>>> anyway for backward compatibility - but it is clear that Context is a
>>> place where storing/retrieving objects identified by a key.
>>> I propose adding two helper methods
>>>
>>>    /** @since 2.0 */
>>>    <T> T retrieve( String key );
>>>
>>>    /** @since 2.0 */
>>>    <T> void store( String key, T object );
>>>
>>> that would help users avoid the redundant code of type cast/checking
>>> when assignments are already known (it throws a ClassCastException if
>>> types are not assignable).
>>> At the same time, old pattern is supported, users can choose their
>>> preferred way to go, depending on their needs.
>>> WDYT?
>>> Many thanks in advance, all the best!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Couldn't find better words, big +1 to your words James!
All the best,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 7:30 PM, James Carman <[hidden email]> wrote:

> To be clear, I am also in favor of this approach.  I don't think we
> need to patronize our users by trying to hold their hands.  A
> ClassCastException would be a pretty obvious indicator as to what is
> going wrong with something like this.
>
> On Sun, Sep 4, 2011 at 12:13 PM, Matt Benson <[hidden email]> wrote:
>> Obviously I've suggested this "auto-cast" or
>> whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
>> use.
>>
>> Matt
>>
>> On Sun, Sep 4, 2011 at 7:39 AM, James Carman <[hidden email]> wrote:
>>> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
>>> and it was shot down
>>> (http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
>>>  Good luck with that.  It wasn't worth my time to continue to argue
>>> about it anymore, so I reverted it.
>>>
>>> On Sun, Sep 4, 2011 at 5:22 AM, Simone Tripodi <[hidden email]> wrote:
>>>> Hi all guys,
>>>> I think that generics could help us on improving the Context class;
>>>> I'm not particularly happy having it extending Map - it is needed
>>>> anyway for backward compatibility - but it is clear that Context is a
>>>> place where storing/retrieving objects identified by a key.
>>>> I propose adding two helper methods
>>>>
>>>>    /** @since 2.0 */
>>>>    <T> T retrieve( String key );
>>>>
>>>>    /** @since 2.0 */
>>>>    <T> void store( String key, T object );
>>>>
>>>> that would help users avoid the redundant code of type cast/checking
>>>> when assignments are already known (it throws a ClassCastException if
>>>> types are not assignable).
>>>> At the same time, old pattern is supported, users can choose their
>>>> preferred way to go, depending on their needs.
>>>> WDYT?
>>>> Many thanks in advance, all the best!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Raman Gupta
In reply to this post by Simone Tripodi-2
On 09/04/2011 05:22 AM, Simone Tripodi wrote:

> Hi all guys,
> I think that generics could help us on improving the Context class;
> I'm not particularly happy having it extending Map - it is needed
> anyway for backward compatibility - but it is clear that Context is a
> place where storing/retrieving objects identified by a key.
> I propose adding two helper methods
>
>     /** @since 2.0 */
>     <T> T retrieve( String key );
>
>     /** @since 2.0 */
>     <T> void store( String key, T object );
>
> that would help users avoid the redundant code of type cast/checking
> when assignments are already known (it throws a ClassCastException if
> types are not assignable).
> At the same time, old pattern is supported, users can choose their
> preferred way to go, depending on their needs.
> WDYT?

Just curious -- what is the advantage of these two new methods over using:

Context<String,Object> context = ...

context.get(k);
context.put(k, v);

Cheers,
Raman

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Raman,
What you wrote is not 100% right, since Context *extends Map<String,
Object>*, so a correct assignment would be:

    Context context = new MyContextImpl();

Context is able to store object identified by a key; let's assume you
store there your DataSource:

    DataSource dataSource = ... ;
    ...
    context.put("datasource", dataSource);

That needs to be retrieved in a Command during the chain execution;
the difference is by invoking `get`

    Object obj = context.get("datasource");
    DataSource dataSource = (DataSource) obj;

And `retrieve`

    DataSource dataSource = context.retrieve("datasource");

That is able to 'auto-cast' the retrieved object while Map#get() not.
HTH, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 9:31 PM, Raman Gupta <[hidden email]> wrote:

> On 09/04/2011 05:22 AM, Simone Tripodi wrote:
>> Hi all guys,
>> I think that generics could help us on improving the Context class;
>> I'm not particularly happy having it extending Map - it is needed
>> anyway for backward compatibility - but it is clear that Context is a
>> place where storing/retrieving objects identified by a key.
>> I propose adding two helper methods
>>
>>     /** @since 2.0 */
>>     <T> T retrieve( String key );
>>
>>     /** @since 2.0 */
>>     <T> void store( String key, T object );
>>
>> that would help users avoid the redundant code of type cast/checking
>> when assignments are already known (it throws a ClassCastException if
>> types are not assignable).
>> At the same time, old pattern is supported, users can choose their
>> preferred way to go, depending on their needs.
>> WDYT?
>
> Just curious -- what is the advantage of these two new methods over using:
>
> Context<String,Object> context = ...
>
> context.get(k);
> context.put(k, v);
>
> Cheers,
> Raman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

James Carman
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>
> That is able to 'auto-cast' the retrieved object while Map#get() not.
>

I believe the feature is actually called "type inference", not "auto-cast."  :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
thanks James!
as you can notice, my English is still poor :)
All the best, have a nice day!!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Sep 4, 2011 at 10:00 PM, James Carman
<[hidden email]> wrote:

> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not "auto-cast."  :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Raman Gupta
In reply to this post by James Carman
On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not "auto-cast."  :)

Thanks for the explanation... I see now that via the generic method
the compiler infers the return type from the assignment type.

Cheers,
Raman

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Matt Benson-2
In reply to this post by James Carman
On Sun, Sep 4, 2011 at 3:00 PM, James Carman <[hidden email]> wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not "auto-cast."  :)

Blame me for the misnomer, and feel free to correct any future uses of
it on my part.  :P

Matt

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Paul Benedict
In reply to this post by Raman Gupta
I want to get rid of it extending map. Have it define as asMap()
function instead. Especially since JDK 8 is bringing in extension
methods, which adds new (and default) methods to all collections, it
won't look very nice. Let's make a break now.

On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <[hidden email]> wrote:

> On 09/04/2011 04:00 PM, James Carman wrote:
>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>>
>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>
>>
>> I believe the feature is actually called "type inference", not "auto-cast."  :)
>
> Thanks for the explanation... I see now that via the generic method
> the compiler infers the return type from the assignment type.
>
> Cheers,
> Raman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
Hi Paul,
I tend to agree with you since I don't like the Map extension too, the
only concern is just to understand how strict backward compatibility
we want to keep, or if we want almost "redesign" the public APIs.
It is an important choose we have to made in a VOTE, I suggest to
promote first the branch in trunk and then understanding if breaking
the compatibility or not.
Thanks for your hints, much more than appreciated!
Have a nice day, all the best!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Sep 5, 2011 at 5:54 AM, Paul Benedict <[hidden email]> wrote:

> I want to get rid of it extending map. Have it define as asMap()
> function instead. Especially since JDK 8 is bringing in extension
> methods, which adds new (and default) methods to all collections, it
> won't look very nice. Let's make a break now.
>
> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <[hidden email]> wrote:
>> On 09/04/2011 04:00 PM, James Carman wrote:
>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>>>
>>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>>
>>>
>>> I believe the feature is actually called "type inference", not "auto-cast."  :)
>>
>> Thanks for the explanation... I see now that via the generic method
>> the compiler infers the return type from the assignment type.
>>
>> Cheers,
>> Raman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

James Carman
In reply to this post by Paul Benedict
I agree with Paul here.  Extending Map (or any other class for that
matter) when what you really want to do is encapsulate it is silly.
Is the Context really meant to be used in any place where a Map can be
used?  I would think not.

On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <[hidden email]> wrote:

> I want to get rid of it extending map. Have it define as asMap()
> function instead. Especially since JDK 8 is bringing in extension
> methods, which adds new (and default) methods to all collections, it
> won't look very nice. Let's make a break now.
>
> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <[hidden email]> wrote:
>> On 09/04/2011 04:00 PM, James Carman wrote:
>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>>>
>>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>>
>>>
>>> I believe the feature is actually called "type inference", not "auto-cast."  :)
>>
>> Thanks for the explanation... I see now that via the generic method
>> the compiler infers the return type from the assignment type.
>>
>> Cheers,
>> Raman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Simone Tripodi-2
I totally agree with you James, what is needed is just to understand
if break the 1.X compatibility or not...
I think that the discussion worths a vote call at that point, WDYT?
Many thanks in advance, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Sep 5, 2011 at 1:21 PM, James Carman <[hidden email]> wrote:

> I agree with Paul here.  Extending Map (or any other class for that
> matter) when what you really want to do is encapsulate it is silly.
> Is the Context really meant to be used in any place where a Map can be
> used?  I would think not.
>
> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <[hidden email]> wrote:
>> I want to get rid of it extending map. Have it define as asMap()
>> function instead. Especially since JDK 8 is bringing in extension
>> methods, which adds new (and default) methods to all collections, it
>> won't look very nice. Let's make a break now.
>>
>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <[hidden email]> wrote:
>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>>>>
>>>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>>>
>>>>
>>>> I believe the feature is actually called "type inference", not "auto-cast."  :)
>>>
>>> Thanks for the explanation... I see now that via the generic method
>>> the compiler infers the return type from the assignment type.
>>>
>>> Cheers,
>>> Raman
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

James Carman
Well, if you're going to a 2.x, then I say break it and do it the
right way.  Consider that my +1.

On Mon, Sep 5, 2011 at 8:51 AM, Simone Tripodi <[hidden email]> wrote:

> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion worths a vote call at that point, WDYT?
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Sep 5, 2011 at 1:21 PM, James Carman <[hidden email]> wrote:
>> I agree with Paul here.  Extending Map (or any other class for that
>> matter) when what you really want to do is encapsulate it is silly.
>> Is the Context really meant to be used in any place where a Map can be
>> used?  I would think not.
>>
>> On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict <[hidden email]> wrote:
>>> I want to get rid of it extending map. Have it define as asMap()
>>> function instead. Especially since JDK 8 is bringing in extension
>>> methods, which adds new (and default) methods to all collections, it
>>> won't look very nice. Let's make a break now.
>>>
>>> On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta <[hidden email]> wrote:
>>>> On 09/04/2011 04:00 PM, James Carman wrote:
>>>>> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi <[hidden email]> wrote:
>>>>>>
>>>>>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>>>>>
>>>>>
>>>>> I believe the feature is actually called "type inference", not "auto-cast."  :)
>>>>
>>>> Thanks for the explanation... I see now that via the generic method
>>>> the compiler infers the return type from the assignment type.
>>>>
>>>> Cheers,
>>>> Raman
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [chain][v2] clever context

Raman Gupta
In reply to this post by Simone Tripodi-2
On 09/05/2011 08:51 AM, Simone Tripodi wrote:
> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion worths a vote call at that point, WDYT?
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

As a chain user, I'd be fine with that for 2.x: +1 non-binding.

Cheers,
Raman

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123