KM8: Local and Instance Variables

What about compatibility of shell use i.e. “$KMVAR_!Myvariable” and relate other languages?
-alain-

Without thinking too much, I don’t see any reason why this should cause problems. The currently used 𝕃 and 𝕀 would be “worse”, no?

¡ and ! are ASCII chars, after all.

And, by the way, you can’t use local variables in shell or AppleScripts, since they are limited to the macro. (They are not in the ENV, unless I’m missing something.)

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

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.

1 Like

Nope. Try this:

[test] Local Vars.kmmacros (2.5 KB)

The same with 𝕀.

1 Like

:+1: => 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?

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).

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

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

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, 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.
1 Like

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)


1 Like

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.

1 Like

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

See also this comment.

1 Like

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

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

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__".

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

Sorry, I should have been clearer.

Ah, glad to hear that :slight_smile:

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.