Understanding 'the defaultStack'

[Monte Goulding]

> On 9 Oct 2016, at 9:10 PM, Jeanne A. E. DeVoto <revolution at jaedworks.com> wrote:
> 
> At 11:23 AM +1100 10/9/2016, Monte Goulding wrote:
>> stack A - is defaultStack in its own script
>> go stack B
>>  stack B preOpenStack - stack B now defaultStack in its own script
>>  go stack C
>>     stack C preOpenStack - stack C no defaultStack in its own script
>>  stack B preOpenStack continues but stack C is now the defaultStack
>> back to stack A script and now stack B is the defaultStack
>> 
>> But if you change it to set to the topStack then when you go back to the stack A script then stack C will be the defaultStack.
> 
> Hmm. I actually would have expected stack C to still be the defaultStack on returning to stack A. defaultStack is a global property, theoretically.

What if stack C is only opened sometimes or stack A doesn’t even know about it. Considering this seriously impacts the function of the remaining stack A script I suspect if you think on it some more you want to be more sure about what will mess with it and how it will mess with it than you are suggesting. Anyway, it’s one of those things that would be near on impossible to change if anyone wanted to so there’s no huge point going down that path.

BTW I think defaultStack shouldn’t really be considered a global property. It behaves much more like a local property most of the time. The only times it behaves like a global property are when application level messages are sent to the defaultStack (suspend, resume, shutdown etc) but as there’s no real guarantee which stack that happens to be at the time the event comes it means most of those events messages end up being handled by libraries to make sure we get them. Those messages probably would have been better sent directly to the application mainstack (or home in the IDE) but that ship has sailed too.

Cheers

Monte