felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Derek Baum <derek.b...@paremus.com>
Subject Re: Gogo
Date Thu, 16 Jul 2009 14:22:25 GMT
2009/7/16 Peter Kriens <peter.kriens@aqute.biz>

> I do agree that we should replace the <> with (). This makes a lot of sense
> and there are not that many filters in use anyway. We could now make filters
> <> if we want.
> [snip]
> About the priority of | and ; ... I remember thinking long and hard about
> this but forgot why I picked this model, it still seems slightly more
> powerful because the newline acts as a ';' with a higher priority than the
> '|' but I am not opposed to switching the priority.

if we agree to use $() for command execution instead of <>
then we can use () for command grouping, and thus the examples below would
work the same in Unix or RFC132 shell:

echo a; echo b | cat
(echo a; echo b) | cat

We could also add a converter to coerce a string into an LDAP filter to make
up for stealing the ().

> I am not sure about throwing an error when a command is not recognized.
> Using its value seems sufficient to me and has some advantages. I do not
> think this would ever confuse me.

It has already confused users on Karaf :-)

A 'command not found' error only occurs if you pass an argument to an
unknown command, otherwise it silently evaluates to itself.

Although this may be apparent to a user at the console, it would be much
more difficult to diagnose in a script containing a mis-spelled command.

I have attached a simple patch to experiment with this to

This patch simply avoids re-evaluating a single argument to an assignment,

x = hello

works as before, but when evaluated in a non-assignment context, it fails if
a 'hello' command is not found.

Variable expansion using ${ab} rather than $ab is still problematic.

the ${ab} notation is in common usage:

   - Unix allows it to delimit the variable name from following text
   - Many Java programs interpret ${xx} as expansion of system properties

It also works in the RFC132 shell, but in this case {ab} defines a closure
and the $ evaulates it.

If you really wanted to capture the result of executing ab, then <ab> or our
proposed $(ab) is the way to go.

This would then allow us to interpret ${ab}, according to its comon usage -
enhanced variable expansion.
We could also usefully add the Unix variable expansion: ${var:-default}


> Nice to get some discussion going! However, please note that this is an
> OSGi RFC. I will update the RFC in the coming weeks and discuss it in CPEG.
> I hope to schedule it then for inclusion in an upcoming compendium.
> I'd like to add one more thing. In Blueprint we spent a lot of time on type
> conversion and I like very much what we got there. I think it would be a
> good idea to use the same type converters, especially because they also
> handle generics when available.

> Kind regards,
>        Peter Kriens

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message