This message is being posted to alert users in advance to a small planned change to SenseTalk’s “property” syntax, and solicit your feedback.
Summary of the Issue
SenseTalk allows several ways to access a property of an object or property list. For this discussion, consider an object that includes a “cost” property:
set part to (partNum:"A214", cost:5.32)
The cost can be accessed in any of these ways:
put part's cost
put part.cost
put the cost of part
put property cost of part
The above will all display 5.32 assuming that cost has not been assigned a value as a local variable. But suppose the script accumulates a cost based on adding up the costs of several parts, like this:
set part1 to (partNum:"A21", cost:1)
set part2 to (partNum:"B32", cost:2)
set part3 to (partNum:"C43", cost:3)
set part4 to (partNum:"D13", cost:4)
put 0 into cost
add part1's cost to cost
add part2.cost to cost
add the cost of part3 to cost
add property cost of part4 to cost
This will all work until the final line. The first three add commands will increase the value of the local cost variable to 1, to 3, and then to 6 (as the various parts’ cost values are added in). The final add command will then try to access a property named “6” in the part4 object, which is probably not the expected behavior!
This happens because the “property cost of part4” syntax is currently defined differently from the other three forms, to treat “cost” as a variable name. It can be made to work the same as the others by putting the word cost in quotes (add property “cost” of part4 to cost). Similarly, the other forms can be made to treat cost as a variable name by enclosing it in parentheses. So it’s not a question of making new functionality available, but of making the behavior consistent across the different syntaxes.
Proposed Change
The Eggplant development and support teams have discussed this discrepancy and concluded that the current implementation should be changed. We propose to change SenseTalk’s “property x of y” syntax to treat “x” as the direct name of the property, so it will behave just like the other 3 syntaxes.
( Note: As you may be aware, the “property x of y” syntax also has a slightly different behavior, in that it will only access a property, not call a function like the other forms will. We don’t think this behavior difference is relevant to the issue at hand, however, and the behavior will not be affected by the proposed change. )
To avoid any possible problems during a future transition, when you use the “property x of y” syntax in your scripts you may want to either specify a quoted property name (e.g., property “x” of y) or a variable name (or more complex expression) enclosed in parentheses (e.g., property (x) of y). These forms are unambiguous and will be treated the same in current and future versions.
Discussion
The drawback to making this change, of course, is that any existing scripts which use the “property x of y” syntax and don’t enclose x either in quotes or parentheses will have to be changed. We will be happy to provide a script to search through all of your scripts for any apparent instances that would need to be changed, and possibly even make the changes for you, by enclosing the variable name in parentheses to preserve the old behavior.
We feel comfortable making this change because we believe that in most cases where the problem syntax is used, the property name really could or should have been quoted, and the script is relying on SenseTalk’s treatment of variables that have not been assigned a value as unquoted literals (in other words, SenseTalk is treating the word as a variable, but is then evaluating the variable as its name since it has not been assigned a value).
Feedback Requested
We would welcome your feedback regarding this planned change. Do you approve of making SenseTalk’s behavior more consistent in this way? Do you anticipate this change will cause you a lot of trouble with your existing scripts?
We never undertake changes of this sort lightly. An important goal is to ensure a smooth transition from one version of Eggplant to the next for all of our customers. We also have a goal of providing a simple, easy-to-learn scripting language with a minimum of inconsistencies or special cases to remember. When these goals conflict, a decision has to be made. We appreciate your patience and understanding in this case.