LiveCode Forums.

@DarScott: As I said above, I don't see the executionContexts going anywhere and its more likely if we did add new debugging functionality then it would use its own new syntax. However, there is a case to be made for making more specific syntax for the types of things people use the executionContexts for.

The reason I thought 'the caller' might make a nice addition to the language is that it helps scripts provide functionality that is more engine-like without depending on the executionContexts (for example, the socket commands tie messages to the object that called the command).

It would also be nice to refashion 'return ... with ...' to set 'it' in the caller (that syntax does exist at the moment, but is only used by libUrl and for no particularly good reason - it was put it to save a string copy IIRC, although that's not really necessary anymore and definitely won't be when we get reference-counted types). [ The only slight caveat with doing this is that 'it' would have to be automatically declared in every handler - since the message path is dynamic, it wouldn't be possible to know in advance whether 'it' was needed or not. That being said, 'it' can probably be considered a language feature so this probably makes a lot of sense ].

I have used 'return ... with ...' only in the context of liburl; I thought it did not work otherwise. That is cool, and I favor it being a full-fledged language feature.

I was asleep when 'do ... in caller' came out, so I'm new to that. I assume it can modify 'it' and even be used to implement caller(). This sounds like something that can be a full-fledged language feature.

There are built-in commands that modify 'it', and they should work even if the calling script does not look at 'it'.

All of the above, should be 'it' safe.

I also favor officially removing the cloud over executionContexts.

I make what might be called components and modules for LiveCode programmers. I feel obligated to declare when I use undocumented or "might change" features. I'd like to minimize that. So far this has not been a problem, but I see it as a potential source of anxiety for my customers.

If dictionary clutter and confusion is a potential problem in blessing such features, then maybe a view option for the level of the user might be handy. The above show up only in advanced view.

(I created a stack library with an external helper--a module, I guess the pair can be called--for LiveCode like sockets ability in iOS where I used a referenced variable and really should have modified 'it'. I might turn it into something more like traditional LiveCode sockets, and the ability to set 'it' will be handy.)

So, a blessing of the above three and 'it' safety would be cool.

A built-in caller()? I use callbacks a lot. It would be nice to avoid having to copy and paste my function. So, though not needed if executionContexts is blessed, it would be nice. And the parent script caveat documented.

I like the notion of being able to make my own commands that are like built-in commands. That is rich, powerful and clean.