felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: Gogo
Date Fri, 17 Jul 2009 10:36:46 GMT
I am not sure I see why we need $( ... ) for evaluation, instead of  
( ... )?

Kind regards,

	Peter Kriens




On 16 jul 2009, at 16:22, Derek Baum wrote:

> 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
> https://issues.apache.org/jira/browse/FELIX-1325
>
> This patch simply avoids re-evaluating a single argument to an  
> assignment,
> so
>
> 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}
>
> Derek
>
>
>>
>>
>> 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
>>
>>


Mime
View raw message