Create account / Log in

namespaces for properties

Topics related to the main Vassal engine.

Moderators: uckelman, Tim M

namespaces for properties

Postby uckelman » February 5th, 2009, 2:03 pm

Thus spake Timothy Mccarron:
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?

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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
uckelman
Site Admin
 
Posts: 8520
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby Brent Easton » February 5th, 2009, 9:40 pm

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:
Me feeling, having viewed MANY modules is that '.' in Map, Board, Zone and Property names is not something that is common. We could prevent any more from being created and add a Validator to report as errors any that already exist?

I agree.

...

rk



Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 2965
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

namespaces for properties

Postby uckelman » February 5th, 2009, 9:44 pm

Thus spake "Brent Easton":
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.

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

--
J.

_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
uckelman
Site Admin
 
Posts: 8520
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby Brent Easton » February 5th, 2009, 9:51 pm

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

Thus spake "Brent Easton":
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.

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

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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 2965
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

namespaces for properties

Postby Brent Easton » February 5th, 2009, 10:00 pm

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)
User avatar
Brent Easton
 
Posts: 2965
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

namespaces for properties

Postby rk » February 5th, 2009, 10:29 pm

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.

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.

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 (http://www.mail2forum.com)
rk
Site Admin
 
Posts: 536
Joined: October 21st, 2007, 3:31 am

namespaces for properties

Postby uckelman » February 5th, 2009, 10:36 pm

Thus spake "Brent Easton":
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 e
xisting $...$ references to ${...}.

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

I am extremely uncomfortable with having no closing delimiter. I think that i
t is asking for trouble with an unskilled user base.

"X is asking for trouble with an unskilled user base."

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

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 doin
g it, not two.


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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
uckelman
Site Admin
 
Posts: 8520
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby tar » February 5th, 2009, 11:33 pm

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

Otherwise you end up with Lisp.

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




_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
tar
 
Posts: 776
Joined: January 2nd, 2008, 6:53 pm
Location: Los Angeles area

namespaces for properties

Postby Brent Easton » February 5th, 2009, 11:57 pm

On 5/02/2009 at 2:29 PM Rodney Kinney wrote:
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.

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.

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.

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
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 2965
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

namespaces for properties

Postby mkiefte » February 9th, 2009, 11:18 am

I've been away for the last week and haven't checked e-mail, but there doesn't seem to be any discussion regarding backwards compatibility.

I kind of liked the idea of escaping $ and do a multiple runs at parsing until nothing changes. And it preserves backward compatibility.

- M.

2009/2/5 Joel Uckelman <uckelman@nomic.net (uckelman@nomic.net)>
Thus spake Joel Uckelman:
$foo = bar;

That should be

$foo = 'bar';







Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

namespaces for properties

Postby Brent Easton » February 9th, 2009, 12:03 pm

I've been away for the last week and haven't checked e-mail, but there
doesn't seem to be any discussion regarding backwards compatibility.

I have plans to cope with backward compatibility. I will write up in detail what I plan to do for discussion.

I kind of liked the idea of escaping \$ and do a multiple runs at parsing
until nothing changes. And it preserves backward compatibility.





_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)
User avatar
Brent Easton
 
Posts: 2965
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests