V4 Properties (Variables) Typed Vs. Untyped (& If Typed, Which Types)

Development
1

The reference manual for V3 doesn’t seem to have much discussion on property (variable) types (numeric, character, boolean, etc.), and as I understand, V3 tries, to some extent, to interpret property types without requiring the module developer to explicitly type them, other than the Is numeric check box for the Dynamic Property and the Global Property but not for Markers. Also, Vassal has several handy built-in properties, but their types don’t seemed to be explicitly stated. I get the impression that Vassal tries to avoid confusing potential module developers with the concept of data types (it may be the underlying Java that induces this “semi-typed” environment). My intent is not to criticize past decisions, but to suggest what I see as a better path forward. I heartily applaud the Vassal team’s efforts to keep the entry bar low for potential module authors.

I believe any processor would need to be told the type of the data it is asked to process. So the burden of providing that information would either fall on some interpretive routine or the authors of V4 and its modules. I think it would be much more efficient to present V4 as a “typed” system and state the data types for the built-in properties in the documentation and require module authors to explicitly “declare” (or choose) a type for each property they add to a module.

I don’t think the concept of data types to be all that difficult to grasp. After all when conceiving of what data and how to use it in a module the author would have to clearly distinguish between the very basic types of numeric versus character data.

I also recognize this approach would require use of a type conversion function or method to use numeric characters defined as character data as a number, or to add and keep leading zeros to a number.

As for which data types, I think the basic types of character (strings), numeric (integers) and boolean (true/false) would be appropriate for providing a great balance between simplicity and flexibility. The module editor could provide a somewhat disguised interface for more advanced types, which I believe is currently being done in V3.

I’d like to see the concept of boolean property types as an option for Dynamic and Global Properties so that they could be used in selection criteria fields rather than comparative expressions.

A couple of recent threads dealing with the topic are: How to keep leading zeros in expression and Special Grid Numbering Not Working with 3.6.7 (Solved!) - #23 by pawnpusher .
Both of these threads stemmed from an area of Vassal with what appears to me as a lot of vagueness as to property typing, Grid Numbering.

2

You have listed two examples of where “vague” typing perhaps causes an issue, not necessarily from the way things are typed but perhaps how it is documented or the workings of a specific functionality. What problems/difficulty would be introduced if properties need to be strongly typed and VASSAL also has to deal with all those types and enforce them? It seems to me like it puts a burden on VASSAL and module designers – who don’t have to be programmers. I think a Javascript-y loose typing is much easier in most cases – store everything as a string internally and interpret as needed. Then you have to identify and solve these few specific cases where that causes issues.

3

Using V3 as a guide or even a starting point here is not a good idea. It’s not how one would do it if given free choice. BreanShell is awkward because everything must be converted to a string.

I don’t see pervasive issues with mistyping in JavaScript. Numeric, boolean, and and string literals have their natural types. If you try to do arithmetic with them in a sensible way, you get sensible results. If you use + with a string as one of the operands, the other is coerced to a string. (E.g., "abc" + 3 evaluates to "abc3"). If you’re trying to do something nonsensical, like subtract from a string, you get nonsensical results—but you have no reason to do that.

4

The dynamic typing approach of V3 works most of the time… However, as I found out when I wanted to keep leading zeros in an expression, there are times when it would be convenient to be able to statically type a variable.

2 Likes