I guess we should have tried this out in a sandbox but this experiment
seems rather harmless for existing users and potentially very powerful.
And
this experiment is timely because I do have to update RFC 147. Will do
different next time :-)
On 4 mei 2010, at 08:33, Guillaume Nodet wrote:
A few things that would be missing imho to make that interesting:
* parameters annotation to mark parameters as optional or multi-valued
How do you see this? We do have the type of the parameter so we can
deduce
it is multi value. However, how do we know the last one? We would need
some
kind of separator. And do not forget that we have real objects, not
strings.
We had not gotten around the optional mandatory part. I think I'd like to
have a special annotation for that.
* flag and option could be merged (they are the same, maybe use an enum
value on the annotation to differentiate them and maybe have a smart
default
value based on the fact that the annotated parameter is a boolean or
not)
Well, it is shorter and easier on the eyes to have different annotations
I
think.
* option should support a list of value
Not sure how this interplays with the type we also have.
* options should have multiple names (annotations support String[]
quite
well)
Ok.
* if we want to add some help information, we need an annotation on the
method
Yes. I think some help on the arguments would also be nice.
* we have a nice coercion mechanism defined in blueprint (handling
generics, collections and such), we should reuse it (without having a
dependency to blueprint)
I agree we should follow the same rules in tsh though implementation code
will differ because the args/options/flags will have to be parsed in the
heart of the method selection algorithm, they directly interfere with it.
The low level type converter should be very similar to the BP type
converter
I think. When working on the BP converter I used a lot of lessons from
tsh.
However, the BP type converter takes generics better into account.
Kind regards,
Peter Kriens
On Mon, May 3, 2010 at 23:25, Richard S. Hall<he...@ungoverned.org>
wrote:
On 5/3/10 16:56, Guillaume Nodet wrote:
On Mon, May 3, 2010 at 21:17, Richard S. Hall<he...@ungoverned.org>
wrote:
On 5/3/10 14:51, Guillaume Nodet wrote:
What are those annotations suppose to actually provide ? It seems
all
they
can do is provide some basic help to the user, but does not really
help
the
user writing complex commands and dealing with complex arguments.
Have a look at an existing example:
http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/commands/src/main/java/org/apache/felix/karaf/shell/commands/GrepAction.java
I think those annotations would not provide the slightest help in
analyzing
such a command line.
I don't think there will ever be a single solution that can help
everyone
implement any possible command. If people need to do something that is
super
complex, then they can always fall back to parsing their own
arguments.
I can agree to that, but then I don't see why it has to be in the
proposed
spec. Having it as a separate module might be a better approach then.
The issue is you cannot easily do what we are trying to achieve in a
separate module since it is modifying how the runtime coerces arguments
when
invoking methods. There is no place to hook into this externally.
However, I
agree that it could be just an implementation-specific feature of the
Gogo
runtime.
I actually talked with Peter specifically about this and he felt the
feature might be worthwhile for the spec, which is why he committed it
there, but nothing is set in stone at this point.
-> richard
At this point, we're just messing around with allowing optional
method
parameters and out of order specification of arguments.
-> richard
On Mon, May 3, 2010 at 19:01,<pkri...@apache.org> wrote:
Author: pkriens
Date: Mon May 3 17:01:53 2010
New Revision: 940514
URL: http://svn.apache.org/viewvc?rev=940514&view=rev
Log:
Annotations for parameters
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java?rev=940514&view=auto
==============================================================================
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Flag.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Flag {
+ String name();
+ String help() default "no help";
+}
Added:
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
URL:
http://svn.apache.org/viewvc/felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java?rev=940514&view=auto
==============================================================================
---
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
(added)
+++
felix/trunk/gogo/runtime/src/main/java/org/osgi/service/command/Option.java
Mon May 3 17:01:53 2010
@@ -0,0 +1,6 @@
+package org.osgi.service.command;
+
+public @interface Option {
+ String name();
+ String dflt();
+}
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
