Stack with the same name loop

[Richard Gaskin]

Thank you for confirming that the engine does not throw an error when 
encountering stacks of the same name.

At the heart of the issue seems to be a difference in how short stack 
names are resolved vs things like topstack.

Though related to the duplicate stack name issue, the core underlying 
cause is a separate item logged here:
https://quality.livecode.com/show_bug.cgi?id=18793

If brought into parity with so many of the functions we safely rely on 
like topstack (instead of the load order that's been there since the old 
MC days), so much IDE code and our workflows could become simplified.

Your notes in Comment 9 in that report are especially helpful.  Thanks 
for the recon.

-- 
  Richard Gaskin
  Fourth World Systems




Brian Milby wrote:

> Yes, but it does not add anything else.  If you do it two times you end up with 2 identically named stacks.  You can save them to disk with different long names and end up with multiple stacks with the same short name but different long name.  My demo is on bug 18793.  It works in the IDE.
> 
> Sent from my iPhone
> 
>> On Oct 7, 2021, at 1:58 PM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> Brian Milby wrote:
>> 
>> > Clone stack avoids the check.  It is not that hard to get
>> > multiple stacks with the same short name but different
>> > long names in memory (in a standalone).
>> 
>> Clone alters the name of the new clone stack.  The engine prepends it with "Copy of ".
>> 
>> AFAIK it's done that since 1998.
>> 
>> 
>> FWIW I did some extensive research on duplicate stack names issues about four years ago, attempting to pin down how the engine behaves and what the IDE does.
>> https://quality.livecode.com/show_bug.cgi?id=1061#c20
>> 
>> TL/DR: The engine has no problem with duplicate short stack names, but some IDE needs will be compromised until there is an adjustment to how the engine internally resolves short stack name references;
>> 
>> Currently the old MC implementation remains in place in which those are resolved by load order (which is almost never what any scripter needs), but more useful would be layer/message path order (which is what most scripts and esp IDE tools need).
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems