Stack name conflicts resolved?

[Richard Gaskin]

Mark Waddingham wrote:

 > The engine has always been 'okay' (I believe) with substacks of the
 > same name when they are owned by *different* mainstacks - the only
 > rule you must follow in your code is that if you are referencing a
 > substack when the 'defaultStack' is not the main stack owning it,
 > then you must use:
 >
 >    stack ... of stack ...
 >
 > Just as you would if you have two controls with the same name in two
 > different groups.
 >
 > There is still the general problem of having multiple mainstacks with
 > the same name, or multiple substacks with the same name with the same
 > owner. Unfortunately, I'm not sure there is a general solution to
 > that (mainly because we use stack <name> as the reference for a
 > specific stack in script, and when you start making cross-stack
 > references, any search order is likely to cause 'surprising' results
 > at unexpected times).

In my ongoing tests it seems to be even better than that.

Apparently referring to a stack by short name will cause the engine to 
resolve it somewhat similarly to how it resolves other universal 
references like image IDs:

1. It looks for the stack in the same stack file as the script
    referring to it.

2. If not found, it searches other open stack files in the order
    in which they were loaded into the environment.

This appears to work well for both substacks and mainstacks (easy enough 
to explore once I commented out line #3199 of revbackscriptlibrary, 
worth doing at least temporarily to see how things run).

Given the apparent simplicity and consistency of how this works, I read 
Ben's post earlier this morning with great interest, which pointed me to 
cases where the engine appears to get confused by stacks with the same name:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232505.html

Since I'd already disabled the IDE's same-name check, I was empowered to 
explore those issues and found what seems to be the heart of at least a 
big chunk of this:

The topstack function returns a value that includes information it isn't 
checking when it attempts its resolution to derive it.

Or more simply, topstack only checks short name, apparently using the 
same load-order search path other stack-name-resolution methods rely on.

E.g.: if I have two stacks both named "foo" but saved to two different 
files, no matter which one is on top "topstack()" will only return the 
long name of the one opened first.

Since topstack includes the path, it would seem reasonable to expect 
that the path would be checked as part of the resolution process, and 
indeed useful if it were.

I included other notes related to this in my other post this morning:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232514.html

...along with the link to a new bug report for topstack:
http://quality.livecode.com/show_bug.cgi?id=18793

This won't handle all possible cases (caveats noted in report), but will 
make the topstack function more reliable across a broader range of 
circumstances, perhaps eliminating a majority of issues relating to 
stack name conflicts.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com