Stack with the same name loop

[Mark Waddingham]

On 2021-10-07 17:25, Brian Milby via use-livecode wrote:
> I would be more of a fan of lowering the engine check to just a
> warning vice a hard error/prohibition.  Like you said, if you don’t
> use the long name then most of the time you are going to reference the
> earliest opened version of the stack (based on the linked list of open
> stacks).  But if you reference an object within the same stack (or at
> least the visible card), it can reference by short name.  I guess I
> should expand my test stack to check that.

I'm not quite sure how the engine would give a warning - the behavior 
being discussed in this thread is the way the IDE deals with how the 
engine deals with a specific case...

In general, the engine will either let something happen or it won't. In 
this specific case, it doesn't let implicit opens of stacks (which is 
what all initial openings of stacks are when you use a 'stack <name>' 
chunk are - given the potential disconnect between what <name> is, and 
what stackfile might actually be loaded) proceed if there is already a 
stack with the same name in memory...

However it *does* send a message 'reloadStack' that can be handled so 
script can decide what to do.

Indeed, this handler could happily let things go ahead:

   on reloadStack pStackName, pPath
     local tOldFilename
     set the name of stack pStackName to (pStackName & "~")
     put the filename of stack pStackName into tOldFilename
     set the filename of stack pStackName to "this is a unique name"
     go stack pPath
     set the name of stack "this is a unique name" to pStackName
   end reloadStack

The IDE chooses not to do this to stop the large number of other issues 
which could arise from having multiple stacks in memory with the same 
name (in an environment where it might happen 'by accident', rather than 
for any particularly controlled reason as might be the case in a 
standalone environment written to cope with it).

> I can see a couple of ways to implement this where it would not impact
> existing code.  First would be a global flag to enable opening of
> files with the same name (default to off/false).  The second would be
> a “force” parameter to the open command which would bypass the check.

I guess my real question here is what would be the purpose of that? i.e. 
What problem does it solve?

Warmest Regards,

Mark.

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