Stack with the same name loop

[Mark Waddingham]

On 2021-10-06 22:30, Mark Wieder via use-livecode wrote:
> That's what I do as well. Kill, then go do something else for a bit.
> 
> Reading the code that invokes this dialog (the reloadstack handler in
> revbackscriptlibrary.livecodescript) isn't much help. It's only the
> IDE that can't handle this, not the engine.
> 
> This would all be moot if the IDE used the long id of the stack
> instead of just the short name of the stack, but that would require
> work.

That isn't true - the problem is a lot deeper than that.

Most 'stack' related engine syntax works with the short name of stacks 
e.g. defaultStack, topStack, stackFiles.

The IDE is built using the engine, so has to work within the limitations 
the engine has.

Internally the engine references stacks by 'weak handles' (basically 
pointers which 'know' when the thing they are pointing at has been 
deleted) - it does not use names... However the way stacks are 
referenced by script (as mentioned above) do use the short name - to 
keep things simple.

Of course it would be possible to add new syntax and such - and it would 
be possible to update the IDE to use it (and thus the 'irksome' dialog 
could be removed).

However, the reality is that, that endeavour (which would be a very 
large amount of work) would only shift the problem - onto users 
themselves.

If user code did not use the new syntax, then chances are they would end 
up causing really hard to track down issues in their own code due to 
having two stacks with the same name. This is regardless of whatever 
resolution order was chosen to resolve conflicts - unless user code also 
uses unique stack references, there is no choice which would not stop 
problems from happening.

I'd like to point out that this is not me copping out here - it is 
merely pointing out that simplicity does come with restrictions - and as 
it stands, one of these restrictions (with livecode) is uniquely named 
stacks.

I'd further point out that 'critical things having unique name' isn't 
that rare. For example, you can't have two files with the same name in a 
folder for example (even though on UNIX systems, every file has an 
internal unique integer id - the inode number) and you can't have two 
handlers, variables, methods, types (or any named thing) with the same 
name (in the same namespace) in any language that I know of.

So, may I suggest, the problem to solve is to figure out why the dialog 
which spawned this thread does not work correctly in some circumstances?

I say some circumstances, because it does work precisely as advertised 
in a (fresh) IDE after it has been started:

   1) Create a stack "Foo" - save it as "FooEmpty.livecode" and remove 
from memory
   2) Create another stack "Foo" - place a button on it and save it as 
"FooButton.livecode"
   3) Load FooEmpty.livecode from the menu - ask to Purge. FooEmpty 
appears (and FooButton goes)
   4) Add a tab control to FooEmpty.
   5) Load FooButton.livecode from the menu - ask to Save, FooEmpty is 
saved and FooButton appears.
   6) Load FooEmpty.livecode from the menu - ask to Purge, FooEmpty 
appears (now with tab control) and FooButton has gone.

The correct behavior of that dialog is precisely what you would expect 
from the button names:

   1) Cancel - the loading of the new stack does not happen.
   2) Purge - the existing stack of the same name is removed from memory 
without saving first, and the new stack is loaded.
   3) Save - the existing stack of the same name is saved and then 
removed from memory, and the new stack is loaded.

The effect observed (the looping) could be an interaction with a 
component in the IDE (which somehow causes the stack which should be 
being removed to be reloaded), or it could be some code pattern in user 
stacks which cause much the same problem. In the former case, we need to 
fix the IDE to be 'purge safe in this case', in the latter case we need 
to understand the pattern so that we can change the mechanism to not be 
affected by it.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps