Hi Elijah,
don't be sorry, OSS is something (almost) everybody does in his spare time ;)
Thanks for the new patch, I'll process during the day as soon as I get
a spare time slot.
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http
Hi Simo and everyone else,
I finally got around to updating the patch to contain comments explaining
what the suppressed unchecked annotations are doing. The patch attached to
CHAIN-61, now has thsse additions. Now, chain *should* compile without
warnings.
Thanks and sorry about the wait,
-Elijah
I've created a new bug: https://issues.apache.org/jira/browse/CHAIN-61 for
dealing with compiler warnings. I want to have chain build cleanly before I
work on the Context signature. I have just attached a patch for the compiler
warnings. I have annotated with @SuppressWarnings and @Deprecated where
Hi Elijah,
by default Maven doesn't show warnings, you have to modify the pom.xml
in that way:
{code}
org.apache.maven.plugins
maven-compiler-plugin
2.1
${maven.compile.source}
${m
Hi Simo,
Funny, I don't believe think that compiler complained at all. I will double
check soon and try some other compilers and let you know soon.
Thanks,
-Elijah
On Mon, Sep 19, 2011 at 8:12 AM, Simone Tripodi wrote:
> Hi Elijah,
> I had e deeper look at your patch and raw more carefully your
Hi Paul,
thanks for the feedback!
I think that your hint is very good but I don't know why something
suggests me that there are situations - like in the web subpackage -
where having a typed Context would prevent undesirable runtime
exception.
Can I ask you please the favor of submitting a patch on
Should the context in the command be parametrized? I don't think
that's such a good idea. Isn't one of the benefits of Chain is that
you don't know which context you might be getting?
Paul
On Mon, Sep 19, 2011 at 10:12 AM, Simone Tripodi
wrote:
> Hi Elijah,
> I had e deeper look at your patch an
Hi Elijah,
I had e deeper look at your patch and raw more carefully your message,
I just have a BIG trouble: when changing the Context interface to
public interface Context extends Map {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
"Context is a
Hi Elijah!
great report, thanks for your effort! :)
I'll have a look at your patch as soon as I get a spare time slot,
I'll let you know ASAP!
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Sep 19, 2011 at 3:52 AM, Elijah Zupancic wr
I just submitted a patch to jira as CHAIN-58. This changes Context to
Context.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi wrote:
> Hi Paul!
> yes it can be done, of course :) I'm not convinced anyway by the heavy
> notation that, modifying the Context, would impact the Comma
Hi Simo,
Sorry I was late replying. I've been away at a wedding.
Honestly, I'm not a big fan of Command>. I
agree with you that the it is syntactically clunky. Moreover, I'm not
convinced that the Context design needs to be improved other than the
addition of generics. It is a simple tool that do
Hi Paul!
yes it can be done, of course :) I'm not convinced anyway by the heavy
notation that, modifying the Context, would impact the Command and
Filter classes. I think it is because just a matter of taste :P
Feedbacks/suggestions/patches are welcome, if you want to provide a
solution feel free t
The basic context should be Context and then use interface
composition to define other things like:
public interface PropertyContext extends Context,
Map
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
wrote:
> Hi Elijah,
> I spent some spare time trying to f
Hi Elijah,
I spent some spare time trying to figure out how to improve the
Context design, I didn't have a lot of success anyway :(
* dropping the Map inheritance makes not easy maintaining the classes
in the 'generic' package;
* adding generics in the Context to specify K,V types, makes all the
Hi Everyone,
I don't have any votes as I'm not a commiter, but I would still like to add
in my suggestion.
After our previous exchange, I'm of the mind that we should use the second
option - that is be collection agnostic and work by composition. I may be
biased towards defined getters and setter
Hi all guys,
after mails and mails of discussions, I don't think there is a general
agreement on how Context API should look alike.
At the end of the discussions I figured out that, briefly resuming, we
have following proposals:
* be replaced by Map;
* be Collection agnostic and work by composit
I honestly still haven't figured out how our Context should look
alike, better if I go sleep (it's almost midnight here in Italy :P)
and thinking about it :)
Good night, I'll come back writing tomorrow!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at
Definitely interesting. I think this might be a special case though;
ClassToInstanceMap is dedicated to class instances which is probably
why they extended Map so that it has extra guarantees. I don't know if
such a pattern is advisable for a regular key/value pair. What are
your thoughts?
On Fri,
indeed, the retrieve method would allow users assigning retrieved
object to all T that extend V, like the ClassToInstanceMap, take a
look at the method signatures[1]
[1] http://s.apache.org/Mno
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Sep 9, 2011 at 11:02 PM, Pau
The purpose of Generics is to provide type safety with the implicit
casts. Implicit casts because of typing shouldn't cause a
ClassCastException. That would break an important principle behind
using gnerics. Are you sure Guava is doing what you're proposing?
Typing should always be safe; I would be
Hi Paul,
the type inference becomes more interesting and useful if you think to
more complicated context instances, take as sample the Guava's
ClassToInstanceMap[1] where values extend a specific base type.
the in the `retrieve` method reduces anyway the number
of errors, given an hypothetically
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic wrote:
> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi
>> wrote:
>>> Hi Paul,
>>> the use of that method is to automatically in
Specifying Object for V would be the most likely use case.
On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict wrote:
> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi
> wrote:
>> Hi Paul,
>> the use of that method is to automatically infer the assigned type,
>> instead of writing
>>
>> MyPojo myPo
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi wrote:
> Hi Paul,
> the use of that method is to automatically infer the assigned type,
> instead of writing
>
> MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> the retrieve method allows to
>
> MyPojo myPojo = context.retrieve( "myKey" );
Hi Paul,
the use of that method is to automatically infer the assigned type,
instead of writing
MyPojo myPojo = (MyPojo) context.get( "myKey" );
the retrieve method allows to
MyPojo myPojo = context.retrieve( "myKey" );
both throw ClassCastException if types are not assignable, but with
In my personal use of Chain, I am using it as . So
typing as Context is good. Though, do we need type T? Shouldn't
retrieve(K) just return V?
On Fri, Sep 9, 2011 at 2:21 PM, Simone Tripodi wrote:
> here I am!
> sorry I'm late but just terminated to have dinner :P
> I think that specifying the ca
here I am!
sorry I'm late but just terminated to have dinner :P
I think that specifying the can be omitted, and
Paul's suggestion is the way to go, the code is more readable.
The last added method can be improved, putting the K as argument
instead of String and as a strict check for output
argum
I go with what I said. Extending from Object is sulfurous since all
type parameters extend at least from Object.
On Fri, Sep 9, 2011 at 1:56 PM, Elijah Zupancic wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedi
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict wrote:
> On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic wrote:
>> Thanks for your comments Nail.
>>
>> I think that I've come around to see your point after sleeping on it.
>> W
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic wrote:
> Thanks for your comments Nail.
>
> I think that I've come around to see your point after sleeping on it.
> What do you think about this:
>
> Context.java - would be defined as so:
>
> public interface Context extends Map
Isn't that identica
Thanks for your comments Nail.
I think that I've come around to see your point after sleeping on it.
What do you think about this:
Context.java - would be defined as so:
public interface Context extends Map
Then ContextBase.java would be defined like so:
public class ContextBase extends Concur
On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic wrote:
> Hi Niall,
>
> The source of the misunderstanding regarding the usage of chain may be
> my fault. Thank you very much for piping up and letting us know some
> of the history regarding the chain project.
>
> I was under the assumption that al
Hi Niall,
The source of the misunderstanding regarding the usage of chain may be
my fault. Thank you very much for piping up and letting us know some
of the history regarding the chain project.
I was under the assumption that all keys of a Context were String
because in ContextBase in the initial
Hi Niall!!!
ok I got you, sounds that instead of improving we put a step down on
the Context.
What is in your opinion the better way to manage the Context,
replacing it with with Map and using generics?
We thought String as a key maybe because influenced by some usecases,
but as you already told it
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi wrote:
> Hi Niall,
> thanks for the hint!
>
> Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
> so I couldn't say the truth) I immagine that users would be interested
> on having, as a Context, not just a place where storing comp
As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity object.
Hi Niall,
thanks for the hint!
Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
so I couldn't say the truth) I immagine that users would be interested
on having, as a Context, not just a place where storing computed
element to be shared between chain commands, but having also
On Mon, Sep 5, 2011 at 12:21 PM, James Carman
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.
I a
Hi Paul,
agreed. I just started indeed a thread vote to accept the new codebase
as /trunk, so we can continue working toward a new releas wich
involves redesigns as well.
I would really appreciate if you and James partecipate in the vote and
could continue co-operate until next release!!!
Have a n
Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.
On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wr
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.
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 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
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,
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 wrote:
> I want t
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
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 wrote:
On Sun, Sep 4, 2011 at 3:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> 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 mi
On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> 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.
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
wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> wrote:
>>
>> That is able
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi 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,
Hi Raman,
What you wrote is not 100% right, since Context *extends Map*, 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 = ... ;
...
c
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/retrie
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 wrote:
> To be clear, I am also in favor of this approach. I don't think we
> need to patronize our users by
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 wrote:
> Obviou
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
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 wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (ht
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 wrote:
> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-
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 wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.
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
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 h
60 matches
Mail list logo
