How do you do a binary tree in AppleScript OSA/sdef?

(Peter N Lewis) #1

I’m looking at expanding AppleScript support for Keyboard Maestro, and if I include Actions as an element, they can have sub-actions, which should be fine. But the case of the If Then Else action, it has two sets of actions - the equivalent for a basic binary tree with left and right branches.

How do you express that in an sdef?

(Mark Alldritt) #2

This is a tough one. Just off the top of my head.

What if you have a “then” action containing all the subactions to be executed if the expression is true and an “else” action containing all the subactions to be executed if the expression is false. The if-then-else action would then have two subactions: the “then” action and the “else” action.

(Peter N Lewis) #3

It seems weird that such a basic structure (binary tree) can’t be represented sensible.

An alternative I considered would be to make an “action list” class which contains actions, and then I could have “if action” and “else action” properties. That would lead to something like:

action 1 of if actions of action 1 of macro "Whatever"

Another option is to duplicate the “action” class to “else action”, and then I could have “actions” and “else actions” in the action class, but that seems pretty ugly.

Darn. I was hoping there was something I missed. I thought maybe I could use “list of actions” as a property type for example, but that doesn’t seem to work. I saw in Matt Neuburg’s “AppleScript The Definitive Guide” “The AppleScript compiler does not enforce the distinction between a property and an element”, but that doesn’t seem to get me anywhere either.

(Mark Alldritt) #4

I don’t think your if sub-actions and else sub-actions element collections idea will work. This is because element collections are grouped by object class, not object meaning. Its not possible to have two element collections with different names/4-character codes that contain the same type of object instances.

Another approach is to have a single collection of sub-actions associated with the if-then-else action, and then have two properties containing an array of references to sub-actions. One property specifying the if sub-actions, and their order, and the other specifying the else sub-actions and their order. Not a great design I grant you, but it is an alternative.