KM8: Local and Instance Variables

[Tom]

I also was unsure, but I tried it in my first KM8 macro, and accessing local variables from the contained AppleScript didn’t work. (getvariable)

I didn’t try it with shell scripts though.

And it seems logic, since they are stored nowhere (“local”). However, it would be indeed great if we were able to access those variables from scripts that are launched by the macro itself (i.e. embedded AppleScripts or shell scripts). But I guess this would be a really major complication.

[Tom]

@alain

Since locality is restricted to KM (if I understand well ) scripting using these local variable is impossible?

Nope. Try this:

[test] Local Vars.kmmacros (2.5 KB)

The same with 𝕀.

[alain]

=> local variables more useful.

Is instance variables are transient (exist only for the current run and are dropped at exit) and with (local) scripting access?

[Tom]

For scripting access there seems to be no difference. None of them are accessible. Have you tried the above test macro with 𝕀?

According to what I understood, Instance variables are accessible to macros that launch the other macro (or viceversa).

[alain]

I have not yet tested KM8 … but I hope quite soon
Thanks for your tests… and more

[Tom]

I have added an Afterthought to my above post. Maybe worth reading.

[JMichaelTX]

@peternlewis

The difference becomes apparent when you call a sub-macro. The sub-macro is in the same execution instance, so it can see (and set) Instance variables. But it cannot see Local variables.

Thanks for the clarification, Peter.

So, since using a Execute Macro is in the same execution instance, shouldn't Execute Script be as well, and thus, instance variables should be available to scripts?

@Tom

Exclamation marks: ¡ Instance, ! Local

@Tom, thanks for your thoughtful and comprehensive discussion.

I am good with your preference of ! and ¡.
The logic is good, keyboard access is good, and the memory association of ! with l for local, and ¡ with i for instance, works for me.

The only drawback is that using these does NOT allow you to quickly select the entire variable name by double-clicking -- it does NOT include the exclamation marks. I need to do this a lot. For example, setting a variable in one action, and then using it in the next, or later, action.

Since you tried two characters, I have done the same, just for comparision:

!SomeLocalName
¡SomeInstanceName

llSomeLocalVarName
iiSomeInstanceVarName

LLSomeLocalVarName
IISomeInstanceVarName

Visually, I still prefer the exclamation marks.

So, @peternlewis, I can support @Tom's suggestion of exclamation marks.

@peternlewis, some other thoughts on this:

• Using "Local " and "Instance " as indicators might conflict with existing macros that use those terms.
• As I suggested above, I think using "Local__" and "Instance__" is better, and maybe you should eliminate the other indicators.

[JMichaelTX]

@Tom

I also was unsure, but I tried it in my first KM8 macro, and accessing local variables from the contained AppleScript didn't work. (getvariable)

Now that understand "local" vs "instance" variables, it seems to me (per my post to Peter above) that instance variables should be accessible to scripts.

But instance variables are NOT available to scripts, at least not to AppleScript. Here my test macro/script:

Example Results

Macro: Instance Variable Test KM8 @TEST

Instance Variable Test KM8 @TEST.kmmacros (2.0 KB)

---

[Tom]

@JMichaelTX

The only drawback is that using these does NOT allow you to quickly select the entire variable name by double-clicking -- it does NOT include the exclamation marks.

This is a good point I hadn't considered.

The !¡ escape from double-clicking because they are punctuation (they are word-breaking). Of course the same is true for ›» and also for £. 𝕀 and 𝕃 are working fine in that respect.

However, as you also have stated, I don't think that this is game breaker. But, maybe somebody comes up with a better solution.

---

As a sidenote, I was quite content with @peternlewis' initial choice (𝕀 and 𝕃). OK, you might need a snippet expander to insert them, but, since we all have KM this shouldn't be a problem. But I'm interested to know why he thinks that the fact that those chars are not on Unicode Plane 0 (BMT) poses a problem.

[Tom]

@JMichaelTX

But instance variables are NOT available to scripts, at least not to AppleScript.

Jim, see my above post. None of them (𝕀 or 𝕃) is accessible from AppleScript nor from shell scripts.

See also this comment.

[JMichaelTX]

@Tom

Jim, see my above post. None of them (𝕀 or 𝕃) is accessible from AppleScript nor from shell scripts.

Thanks, @Tom. I missed that you had also tested instance variables.
My results confirm yours.

[JMichaelTX]

@Tom

As a sidenote, I was quite content with @peternlewis' initial choice (𝕀 and 𝕃). OK, you might need a snippet expander to insert them, but, since we all have KM this shouldn't be a problem. But I'm interested to know why he thinks that the fact that those chars are not on Unicode Plane 0 (BMT) poses a problem.

I don't know Peter's reasoning, but I can see how those characters would be harder to use in general, for most users.

[Tom]

@JMichaelTX

As I suggested above, I think using "Local__" and "Instance__" is better, and maybe you should eliminate the other indicators.

Not sure what you mean with "the other indicators". But if you mean to eliminate the single-char sigils (like currently 𝕀 and 𝕃) then I wholeheartedly disagree. A short sigil (whatever it will be) is absolutely needed, I will definitely not prefix every variable with strings like "Local " or "Local__".

[JMichaelTX]

@Tom

Not sure what you mean with "the other indicators". But if you mean to eliminate the single-char sigils (like currently 𝕀 and 𝕃) then I wholeheartedly disagree.

No, that is NOT what I meant.
By "other indicators" I meant "Local " and "Instance ".

Sorry, I should have been clearer.

[Tom]

@JMichaelTX

No, that is NOT what I meant.

Ah, glad to hear that

[Tom]

Concerning "Local " and “Local__” I agree with you in that the “Local__” (without any space) is needed for the User Prompts (well, once they begin to work with local variables ;))

It would be good to permit both variants, and maybe even “Local_” (with a single underscore) for non-User-Prompt cases where you don’t want to have spaces in the name.

[JMichaelTX]

@Tom

It would be good to permit both variants, and maybe even "Local_" (with a single underscore) for non-User-Prompt cases where you don't want to have spaces in the name.

This is the old simple vs flexible debate.

I usually prefer flexible, but in this case I think I prefer simple -- just have two indicators:

Local

1. !SomeLocalVar
2. Local__SomeLocalVar

Instance

1. ¡SomeInstanceVar
2. Instance__SomeInstanceVar

Both Local and Instance need to work with Prompt Actions.

[Tom]

@JMichaelTX

I usually prefer flexible, but in this case I think I prefer simple -- just have two indicators:

But I don't see any disadvantage in allowing all three connectors (" ", "_", "__"). If you are thinking in backwards compatibility: I don't think that many folks have used "Local_" as a variable prefix. But I might be wrong.

@JMichaelTX

Both Local and Instance need to work with Prompt Actions.

Yep, of course. When mentioning "local" I implicitly meant both types. Sorry for not being clear.

[JMichaelTX]

@Tom

But I don't see any disadvantage in allowing all three connectors (" ", "_", "__").

This is not a big deal to me, one way or the other.
So, I'm happy to let @peternlewis decide whatever he thinks is best.

Here are my thoughts on disadvantages of including "Local_"

• One more case to program for
• One more case for people to quickly recognize
• I don't see any advantages of "Local_", but that is just my personal preference/opinion. LOL

[trych]

@JMichaelTX

but typed-string triggers can't be used within KM Editor app itself.

Wait, what?
I can use typed-string triggers in the KM Editor without any issues:

Keyboard Maestro - 𝕃.kmmacros (2.4 KB)