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.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
