On 2016-10-09 22:25, Jeanne A. E. DeVoto wrote:
At this point, I'm starting to wonder whether the defaultStack should
be redesigned/re-specced to make it more predictable.

I don't think it's feasible to actually make major changes in the way
the defaultStack works, but possibly a new property could be designed
that acts in such a way that workarounds like this aren't normally
needed. Setting and re-setting the defaultStack to make sure it's
right is almost as annoying as specifying the stack every time you
refer to an object (which I sometimes do anyway, for fear of the
defaultStack changing from under me).

If it were being designed from scratch, what would the ideal behavior
be for a targetStack property? Should it remain unchanged while a
script is running (unless set explicitly)?

I don't think its even possible to add a new property which works 'better' (by some metric) as the defaultStack is what is used to 'fill in' missing stack references in chunk expressions - thus its defaultStack, or something else, but not both (otherwise there's no way for the engine to know whether you want to use the new fangled targetStack for that purpose, or the old fashioned defaultStack for that purpose - in any one case).

I wonder if there are just some cases in the current behavior which need some review and refinement - in particular, the scope of the changes to the defaultStack.

One thing to consider is what the locality of a change should be. In particular:

1) If the defaultStack is changed in a handler, should it remain that way for all subsequent commands (which don't explicitly change the defaultStack) and should the change recurse into called functions and commands?

2) If the defaultStack is changed in a handler called from another handler, should the change propagate back up to the caller?

I think (1) is definitely wanted. If you have changed the defaultStack in a handler, then it makes sense that anything executed within that handler, and any handlers invoked within it should use that context.

I think (2) is definitely not wanted. If the locality of a change to the defaultStack propagates back to callers, then the callers loose control and knowledge of what they are actually acting on.

If changes propagate down, and not up then all we need to do is mark commands which explicitly change the defaultStack as doing so. e.g.

  1) go stack tStack - open stack tStack and set the defaultStack to it

  2) set the defaultStack to tStack - set the defaultStack to tStack

3) send tMessage to tObject - execute tMessage in the context of tObject, setting the defaultStack to the stack of tObject for the duration of the handler

4) call tMessage to tObject - execute tMessage of tObject, leaving the defaultStack untouched

With that in mind then the proposed 'using' clause would basically just be a local push / pop of the defaultStack:

  using stack "foo"
  end using

Would be equivalent to:

  put the defaultStack into tOldDS
  set the defaultStack to "foo"
  set the defaultStack to tOldDS

Anyway, the above is just a suggestion (on the whole) - I'm not sure the above to rules (i.e. defaultStack changes propagate into callees, not back into callers) necessarily model the current usage that well or not. However, they are (at least) relatively easy to write down and understand (?).

Warmest Regards,


Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to