Skip to content

ID_Literals

Jump to bottom
Christoffer Fink edited this page Sep 1, 2014 · 5 revisions

In InPUT version 0.5, essentially any string is a legal ID. The only problem is that some IDs may be difficult to use within the configuration. For example, when defining a numeric parameter relative to another parameter, referencing that other parameter in an expression becomes problematic when its ID includes mathematical operators or whitespace.

As the ID literals tests show, whitespace, mathematical operators, and other special characters are allowed. IDs may also begin with any character. The only exception seems to be that an ID cannot contain a newline, and so IDs cannot begin with one either. However, the testing is not exhaustive.

The InPUT4j documentation also recommends that users avoid IDs that start with a lower case letter. InPUT4j uses camel-cased parameters for internal configuration. So, to avoid parameter ID clashes, users are discouraged from using the same naming convention.

Note that it is legal to produce configurations with ambiguous parameter IDs and outright duplications. InPUT4j v0.5 also does not always take scoping into account, and so parameters with the same relative ID may potentially collide. In other words, giving a parameter the same relative ID as a parameter in an outer scope is invalid, even though their absolute IDs differ.

Example (invalid)

    <NParam id="X" exclMin="0" />
    <SParam id="Point">
      <NParam id="X" type="integer" inclMax="0" />
      <NParam id="Y" type="integer" />
    </SParam>

Here there is some parameter with absolute ID 'X'. The x-coordinate of the point has absolute ID 'Point.X'. This arrangement may seem reasonable, but this configuration only defines one parameter with relative ID 'X'; the one with absolute ID 'Point.X'. That is, both 'X' and 'Point.X' exist, but they have the same definition. It may therefore come as a surprise to the user that the point has an x-coordinate that is always positive. Hence this configuration is invalid.

Suggestions for Future Versions

IDs should either be legal or illegal. An ID should not be allowed in one situation and then cause problems in another situation. For example, using an ID such as 'Some-Parameter' would (in v0.5) work fine on its own, but it may not be immediately obvious why it causes problems when defining another parameter with inclMin="Math.log(Some-Parameter)".

This regular expression is a suggestion for legal IDs.

    [_a-zA-Z]+[._a-zA-Z0-9]*

That is, parameter IDs may contain alphanumeric characters, dots (.), underscores (_), and they must begin with a letter or underscore.

Examples (legal)

  • 'SomeParameter'
  • 'Some_Parameter'
  • 'X1'
  • 'X.5'
  • '_123.X'

Examples (illegal)

  • '8ball'
  • 'Some-Parameter'

Another issue is the recommendation to avoid leading lower case letters.

Each parameter ID that is used for internal configuration could be added to a list of reserved IDs, and/or they could be more awkwardly named. Using an awkward naming convention, such as a double underscore prefix and suffix, would make accidental collisions unlikely. Unfortunately, it would also make the IDs appear more arcane and less user-friendly.

There are two ways to mitigate this. First of all, the user could (and should) use constants rather than literal strings when referencing the InPUT configuration parameters. So the user should do InPUTConfig.setValue(Q.RUNTIME_VALIDATION, true) rather than InPUTConfig.setValue("runtimeValidation", true).

Another option that is even more convenient for the user would be to offer ways to set these standard parameters directly. Such as InPUTConfig.enableRuntimeValidation().

However, note that there are currently no tests to demonstrate that duplicating an ID used for internal configuration causes any problems.

It should be possible to control the behavior of InPUT so that name collisions either produce warnings or errors. They should never be ignored. Which mode is more suitable as the default may be debatable.

Due to interactions with other frameworks, it may be impossible to prohibit the use of dots in an ID. However, it is questionable whether spaces should be allowed. This depends very much on the way String parameters are defined.

Since Strings get their value from the ID attribute, these changes would have implications, but there are ways to deal with that. For example, String values could be set using the fixed attribute.

Relevant Tests

Clone this wiki locally