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/
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,
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
Hi Elijah,
by default Maven doesn't show warnings, you have to modify the pom.xml
in that way:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.1/version
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
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 ContextK, V extends MapK, V {
}
you can easily note that, in Command interface (just to mention one)
compiler complains:
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
simonetrip...@apache.org wrote:
Hi Elijah,
I had e
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
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 simonetrip...@apache.orgwrote:
Hi Elijah,
I had e deeper look at your patch and
Hi Simo,
Sorry I was late replying. I've been away at a wedding.
Honestly, I'm not a big fan of CommandK, V, C extends ContextK, V. 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.
I just submitted a patch to jira as CHAIN-58. This changes Context to
ContextK,V.
Thanks,
-Elijah
On Fri, Sep 16, 2011 at 2:16 PM, Simone Tripodi simonetrip...@apache.orgwrote:
Hi Paul!
yes it can be done, of course :) I'm not convinced anyway by the heavy
notation that, modifying the
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 basic context should be ContextK, V and then use interface
composition to define other things like:
public interface PropertyContext extends ContextString, Object,
MapString, Object
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
simonetrip...@apache.org
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
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
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
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 ContextK extends Object, V extends Object extends MapK, V
Then ContextBase.java would be defined like so:
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic eli...@zupancic.name 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 ContextK extends Object, V
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51 AM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic eli...@zupancic.name wrote:
Thanks for your comments Nail.
I think that I've come around to see
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 eli...@zupancic.name wrote:
Paul,
You may be right. Which one is more idiomatic?
Thanks,
-Elijah
On Fri, Sep 9, 2011 at 11:51
here I am!
sorry I'm late but just terminated to have dinner :P
I think that specifying the extending Object 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 T extends V as a
In my personal use of Chain, I am using it as String, Object. So
typing as ContextK, V 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 simonetrip...@apache.org wrote:
here I am!
sorry I'm late but just terminated to have
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
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org 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 =
Specifying Object for V would be the most likely use case.
On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi Paul,
the use of that method is to automatically infer the assigned type,
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic eli...@zupancic.name wrote:
Specifying Object for V would be the most likely use case.
On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict pbened...@apache.org wrote:
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi
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 T extends V in the `retrieve` method reduces anyway the number
of errors, given an
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
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,
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
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
On Tue, Sep 6, 2011 at 9:39 AM, Simone Tripodi simonetrip...@apache.org 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
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
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
On Fri, Sep 9, 2011 at 12:25 AM, Elijah Zupancic eli...@zupancic.name 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
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
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
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 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
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
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 simonetrip...@apache.org wrote:
I totally agree with you James, what is needed is just to understand
if break the 1.X compatibility or not...
I
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
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 rocketra...@fastmail.fm wrote:
On 09/05/2011
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
On Mon, Sep 5, 2011 at 12:21 PM, James Carman
ja...@carmanconsulting.com 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?
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
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
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 ja...@carmanconsulting.com wrote:
Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
and it was shot down
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 gudnabr...@gmail.com wrote:
Obviously I've suggested this auto-cast or
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 ja...@carmanconsulting.com wrote:
Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
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
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
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 ja...@carmanconsulting.com wrote:
To be clear, I am also in favor of this approach. I don't think we
need
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
Hi Raman,
What you wrote is not 100% right, since Context *extends MapString,
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 = ...
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi simonetrip...@apache.org 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 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
ja...@carmanconsulting.com wrote:
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
On 09/04/2011 04:00 PM, James Carman wrote:
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi simonetrip...@apache.org
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
On Sun, Sep 4, 2011 at 3:00 PM, James Carman ja...@carmanconsulting.com wrote:
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi simonetrip...@apache.org
wrote:
That is able to 'auto-cast' the retrieved object while Map#get() not.
I believe the feature is actually called type inference, not
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
60 matches
Mail list logo
