I am in two minds here
1. We have standard ($variable$) that has been used for several years, developers are comfortable with, is simple and works.
2. We have a specific problem (embedded $name$ references e.g. %blah$count$$) that is difficult/messy to implement in the current scheme.
I emailed Brent about exactly this thing earlier in the week. I think it
would save us no end of trouble in the long run if we switched to balanced
delimiters or just omitted the final delimiter entirely.
Personally, I would be happy to replace $variable$ with ${variable} and make it mandatory, i.e. not $foo, only ${foo}. We would need to auto-convert all existing $...$ references to ${...}.
I am extremely uncomfortable with having no closing delimiter. I think that it is asking for trouble with an unskilled user base.
Because we have allowed any characters to be used for component names in the past, {} would often be necessary. It is much simpler to have one way of doing it, not two.
Creating a scripting language with wierd syntax is not a good idea.
The Vassal scripting language will be straight Java using Beanshell.
Where is there actually a problem? Where are these nested constructs trying to be used?
1. As targets in fields that allow $...$ expressions.
2. In Property Match Expressions.
I plan to replace both of these by Beanshell, so these will become proper Java expressions instead of the custom code we have now.
foo would be "foo"
$foo would be foo
$$foo would be getVariable(foo)
Once this is in place, the only remaining use of $variable$ constructs will be back in the Formatted reports where they originally started and work quite well.
B.
*********** REPLY SEPARATOR ***********
On 5/02/2009 at 2:20 PM Joel Uckelman wrote:
Thus spake Jeffrey Brent McBeth:
In trying to write a response to this paragraph, I've convinced my
self each to the two suggestions is the best several times. Perhaps
the problem is that quoting and eval protection (speaking as an old
LISP guy) are different solutions to a similar problems, especially
since we are looking at something that is implicitly recursive. The
choice of the character \ to escape the $ is difficult, as it is the
escape character for C and therefore shells, and escaping is
implicitly single levelled (case in point '\\n' resolves to '\n' not a
newline). I suspect that if the suggestion had been to double up the
$ instead, it would have triggered recursion in most coder's heads and
the Unix coder preference would have leaned toward rk's
interpretation. It is too bad that we (spoken as someone that
hasn't committed a line of code) picked balanced $ rather than () <> or
something else with seperate open and close characters that makes
nesting more visible and parseable (abc(xyz)def)
I emailed Brent about exactly this thing earlier in the week. I think it
would save us no end of trouble in the long run if we switched to balanced
delimiters or just omitted the final delimiter entirely.
E.g., you have this in Perl:
$ denotes the start of a variable name, which runs until you hit a
character
which is not permitted in variable names. (IIRC, [a-zA-Z0-9_] are the
permissible characters, which is pretty usual for identifiers in
programming
languages.) If you need to construct the name of a varible, you can iterate
the $, like so:
$foo = bar;
$bar = 1;
print $$foo;
This will print '1', because $foo evaluates to 'bar', and the value of $bar
is 1. If you need delimiters for disambiguation, you can wrap
subexpressions
with curly braces:
print ${$foo};
which would have the same result as above.
Creating a scripting language with wierd syntax is not a good idea.
_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org
Post generated using Mail2Forum (
http://www.mail2forum.com)
