Create account / Log in

namespaces for properties

Topics related to the main Vassal engine.

Moderators: uckelman, Tim M

namespaces for properties

Postby uckelman » February 4th, 2009, 3:52 pm

Thus spake "Brent Easton":
The actual notation to access a property will be

$Xfiles.Nevada.Area51.UFO$

The following options make sense:

$map.property$ - A Map level property
$map.zone.property$ - A Zone level property on any board
$map.board.zone.property$- A Zone level property on a named board

Question: Is '.' the right seperator to use? What about:

$Xfiles:Nevada:Area51:UFO$

I associate ':' (actually '::') with class scope, and '.' with child object
access, due to my C++ background. Java uses '.' for both.

In one of these expressions, each level of the hierarchy is a concrete
object, not a type, yes? If that's the case, then current convention
favors '.'.

--
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: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby rk » February 4th, 2009, 8:15 pm

Cool. I think '.' is the right separator. It is legal in property names today, though, so it could break some modules unless you explicitly check for exact matches.

Any chance of swapping in some of the values dynamically as in

$Xfiles.Nevada.$currentZone$.UFO$

Then you could refer to like-named zones on different maps, for example. Could have a use in double-blind scenarios.

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 Brent Easton » February 4th, 2009, 8:42 pm

Cool. I think '.' is the right separator. It is legal in property names
today, though, so it could break some modules unless you explicitly check
for exact matches.

Partly, we would be protected from this. If the NameSpace lookup fails, I drop through and check for Global Variables with the full name. So Global Variables containing a '.' will still work. It could be a problem if Map or Zone Property names have a '.' in them.

Should we write a PropertyNameConfigurer that does not allow '.' to be used? (Actually a RestrictedStringCongfigurer that does not allow a specified list of characters).

Hmmm. It also means that Map, Board and Zone names should not include '.'.

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?


Any chance of swapping in some of the values dynamically as in

$Xfiles.Nevada.$currentZone$.UFO$

Then you could refer to like-named zones on different maps, for example.
Could have a use in double-blind scenarios.

This is actually quite easy in the property lookup code, however it's a problem at parsing time. The parsing of the $ signs is done at a higher level, and that is a completely legal string that would parsed as:

Property '$Xfiles.Nevada.$' plus String 'currentZone' plus Property '$.UFO$'

There is not way to tell by inspection whether you want that, or an embedded property evaluated

We would need some other way of including embedded dynamic values.




_______________________________________________
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: 3090
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

namespaces for properties

Postby uckelman » February 4th, 2009, 10:12 pm

Thus spake "Brent Easton":
There is not way to tell by inspection whether you want that, or an embedded
property evaluated

We would need some other way of including embedded dynamic values.

You need a way of guarding dollar signs. This reminds me of something I've
done in Perl in the past, where you construct as a string some complex
expression, and then you eval() it to get variable interpolation. E.g.:

eval(eval('\\$foo$bar'))

would give you the value of the variable whose name is foo concatenated
with the value of the variable bar. So, if $bar = 'wozzle', then this
mess would give you the string '$foowozzle' after the first eval(), and
then the value of the variable $foowozzle after the second eval().

(NB: I don't recall if I have the syntax exactly right. The point of
doubling the backslash is so that it evals to a single backslash which
then guards the $ in the second eval.)

--
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: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby rk » February 4th, 2009, 10:35 pm

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.

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

namespaces for properties

Postby Brent Easton » February 4th, 2009, 10:43 pm

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.


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.



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.

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

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

namespaces for properties

Postby uckelman » February 4th, 2009, 10:48 pm

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

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?

Good Idea.

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

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

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

namespaces for properties

Postby Brent Easton » February 4th, 2009, 11:17 pm

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?

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.




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.

I knew you where going to say that :)

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

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

namespaces for properties

Postby uckelman » February 4th, 2009, 11:34 pm

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?

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 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.

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.

I knew you where going to say that :)

Heh.

--
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: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby rk » February 5th, 2009, 1:23 am

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?

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

namespaces for properties

Postby uckelman » February 5th, 2009, 11:42 am

Thus spake Rodney Kinney:
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.


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

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

namespaces for properties

Postby uckelman » February 5th, 2009, 1:20 pm

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.

--
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: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby uckelman » February 5th, 2009, 1:22 pm

Thus spake Joel Uckelman:
$foo = bar;

That should be

$foo = 'bar';


--
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: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

namespaces for properties

Postby Tim M » February 5th, 2009, 1:35 pm

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:
$foo = bar;

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 (http://www.mail2forum.com)
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1812
Joined: December 8th, 2007, 12:22 pm
Location: Earth

namespaces for properties

Postby timpelican » February 5th, 2009, 1:43 pm

On Thu, February 5, 2009 1:35 pm, Timothy Mccarron wrote:
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?

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

Post generated using Mail2Forum (http://www.mail2forum.com)
timpelican
 
Posts: 171
Joined: January 2nd, 2008, 3:50 pm

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests