namespaces for properties

I agree.

For parsing, as Joel says, if the syntax is just $Xfiles.Nevada.$currentZone$.UFO$ then the existing parsing code ought to work, since SequenceEncoder will produce Xfiles.Nevada.$currentZone$.UFO as the property name. Then all you’d have to do is run the property name itself through property substitution before evaluating it.

rk

Post generated using Mail2Forum (mail2forum.com)

Ok, I will try and get at least the RestrictedStringConfigurer in for 3.1. It would be nice to prevent anyone creating any using 3.1.

Good Idea.

I will keep efficiency in mind while coding, but accessing global variables via Namespace is not going to be terribly efficient.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I think Rodney has his example backwards, as I would expect
$Xfiles.Nevada.$currentZone$.UFO$ to give you the value of the oddly-named
variable Xfiles.Nevada.$currentZone$.UFO. Was
$Xfiles.Nevada.$currentZone$.UFO$ what was meant?

What’s going to be the inefficient part? x.y.z is a branch in a tree, so it
should be possible to make retrieval logarithmic in the number of nodes.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I understand teh argument, but I think

$Xfiles.Nevada.$currentZone$.UFO$

is more in keeping with current usage than

$Xfiles.Nevada.$currentZone$.UFO$

We have 100% control over the parser, so we can go either way.

I’m thinking Property names etc. should also be restricted from having '' and ‘$’ in them.

I knew you where going to say that :slight_smile:

I merely meant it will be inneficient as compared to a non-namespace reference which is a direct hashmap lookup and so is constant, with no need to parse the reference.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I’m not saying that one of these should be invalid, just that the latter
is the one you want if you’re planning to get another variable name after
the first evaluation.

Heh.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

No. As currently implemented, when SequenceEncoder sees $abc$xyz$def$ and looks for the next token delimited by ‘$’ it will remove the ‘’ characters and return abc$xyz$def, which is just what we want in this case.

rk

Post generated using Mail2Forum (mail2forum.com)

Thus spake Rodney Kinney:

I think that’s exactly backwards from the way variable evaluation should
work, then. The natural way to read $abc$xyz$def$ is as a variable name
which contains some odd characters. If what you want is the value of $xyz$
to be interpolated into the name of the larger variable, then what I’d
expect to see is $abc$xyz$def$. This is going to be horribly confusing
for people otherwise.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Jeffrey Brent McBeth:

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.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Joel Uckelman:

That should be

$foo = ‘bar’;


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

why not

$foo = $bar

as a mathematical expression goes ‘bar’ is not the same as $bar
shouldn’t that logic carry here and I thought we were able to now parse the variable on either side of the operator?

From: Joel Uckelman uckelman@nomic.net
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Thursday, February 5, 2009 7:22:42 AM
Subject: Re: [Feature Requests]RFE [1637066] namespaces for properties

Thus spake Joel Uckelman:

That should be

$foo = ‘bar’;


J.


Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org

Post generated using Mail2Forum (mail2forum.com)

On Thu, February 5, 2009 1:35 pm, Timothy Mccarron wrote:

Value vs reference.

$foo = $bar sets $foo equal to whatever $bar equals right now. If $bar
subsequently changes, $foo doesn’t.

$foo = ‘bar’ effectively creates a reference to $bar, such that ${$foo}
equals whatever the value of $bar is at the point when it’s evaluated.

Regards,
Tim.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Timothy Mccarron:

That would assign the value of $bar (which is 1 in my example) to $foo, which
is not what was intended. I wanted to put $bar’s name into $foo, not $bar’s
value.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I have just about finished Restricting the characters in Board, Map, Zone and GlobalProperty names and adding Validators. I am restricting the use of ‘.’, ‘$’ and ‘’ in the names.

Because some components automatically create Global Properties using the name of the component, the following components will also be name restricted:

DiceButton
SpecialDiceButton
Turn Tracker Levels

B.

*********** REPLY SEPARATOR ***********

On 4/02/2009 at 2:35 PM Rodney Kinney wrote:

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

I would strongly recommend permitting only a-zA-Z0-9_ in variable names.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

On 5/02/2009 at 10:44 PM Joel Uckelman wrote:

Yes, that would be nice in a perfect world. Is it something we actually want to implement?

Since NameSpace references will include the names of Maps, Boards and Zones, the names of these components will also have to follow these rules.

The default name of every map in every module is ‘Main Map’ which is illegal under these rules and thus the majority of modules will fail validation and generate errors.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

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.

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.

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:


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

That’s the right thing to do. Beanshell is a more expressive solution, so we should use it instead of extending the $…$ syntax for these more complex cases.

rk

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

There’s no problem with having no closing delimiter so long as you restrict
the characters which can occur in variable names.

“X is asking for trouble with an unskilled user base.”

Exercise: Find and X which makes this statment false. :slight_smile:

It’s nice to be able to drop delimiters which aren’t necessary for
disambiguation. Otherwise you end up with Lisp.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

On Feb 5, 2009, at 2:36 PM, Joel Uckelman wrote:

Which, IMO, would make an excellent scripting language for Vassal!


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Ok. I am going to can

RFE [1637066] namespaces for properties

for now and commit to introducing BeanShell in 3.3.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)