Stack name conflicts resolved?

Tue Nov 8 11:28:12 EST 2016

I made no reference to stack ID; I'm familiar with its role as a 
container for the ID incrementer.

The short name of a stack is not the only distinguishing attribute.  Its 
file path is also available.

Indeed, topstack returns the path as a part of the stack reference, but 
apparently does not check the path when resolving that reference.

I wrote an example function showing how this can be handled in script 
using information we have available today, included in Comment 1 in the 
bug report I filed on this:
http://quality.livecode.com/show_bug.cgi?id=18793

Of course the engine could do that far more efficiently, and indeed it 
would require fixing this in the engine because LiveCode doesn't provide 
a means of overriding built-in functions.

Once fixed, we'll be able to open up old copies of our stacks to check 
or copy things, or open up another project that happens to have a stack 
named something common like "About" which we may have in the one we're 
working on, or any number of other cases which have given rise to 
discussions of workarounds here.  Many such workflows would become as 
graceful as the language itself.

SuperCard had no such limitation, and IIRC neither did OMO, Gain 
Momentum, Tookbook, or even HyperCard.

Indeed, the LiveCode engine itself has no such prohibition:  it allows 
opening stacks with the same name, and any references using a stack's 
short name are resolved using a simple and predictable rule:

The stack containing the script is checked first, and if not found it 
checks stacks in the order they were loaded during the current session.

The only limitation with this is what Ben pointed me to, problems 
copying and pasting objects or other actions dependent on topstack or 
other things related to the stack reference resolution topstack relies 
on, like default stack.

Topstack is normally the stack with the highest layer of the lowest mode.

But in the current engine resolution, when given a short name it appears 
to use load order only, without taking into account window layer.

Since two different stack files will have different paths (as Mark 
Waddingham reminded us, file systems enforce that very consistently for 
us), most issues with working on multiple stacks with the same value in 
the name property go away once the stack resolution uses available path 
information to return a more accurate value.

Given the long history of the IDE and engine development, I can 
understand how we got where we are.  The IDE has been owned by LiveCode 
Ltd. far longer than the engine, and back then prohibiting stacks from 
have the same name value was by far the simpler option. And once that 
was in place, it was no longer possible to explore the issue further, so 
it's remained that way so long we've all just come to accept that it's 
just how things are.

But once I experimented with disabling the IDE block, I was at last able 
to explore the engine behaviors in isolation.  They're generally pretty 
good, in almost all respects as flexible as what SuperCard provides, 
with the sole exception of an incomplete algorithm used for internal 
resolution of the stack reference.

And since that can be done in script, it would seem reasonable to at 
least suggest looking into how this might be refined in the engine.

-- 
  Richard Gaskin
  Fourth World Systems

Bob Sneidar wrote:

> As he said, the stack ID is not really it's ID. In other words LC does not use the stack ID to identify it. Think of the stack ID as "the next ID to be assigned to a new object" much like SQL maintains a value in a master table of some sort with the next unique ID for each unique numerical column.
>
> So unlike any other object whose unique-ness can be determined by it's ID, a stack can only be differentiated by it's name.
>
> Bob S
>
>
>> On Nov 5, 2016, at 11:28 , Richard Gaskin <ambassador at fourthworld.com> wrote:
>>
>> I've grown weary of stack name conflict over the years, and this morning decided to take some time to assess where we're really at with that and see if perhaps there's a way to handle things more liberally than how the IDE does now.
>>
>> TL/DR version:  It seems there's actually no real problem at all.
>>
>> Long version:
>>
>>
>> Setup
>> -----
>> I checked revfrontscriptlibrary and found that preOpenStack calls revIDEHandleNewStack, which resides in revbackscriptlibrary.
>>
>> In that handler I found this line #3199, which I commented out:
>>
>>  revCheckStackCollision tStackName
>>
>> That handler is apparently the one that compares the stacks in the stack file being opened against a list of stacks already open, and if any stack of the same name is found it brings up the stack name conflict warning.
>>
>> After commenting it out I made two stacks:
>>
>> mainstack:  tA
>> substack:  foo
>>
>> mainstack   tB
>> substack:  foo
>>
>> On each mainstack is a button with:
>>
>>  on mouseUp
>>     toplevel "foo"
>>  end mouseUp
>>
>> Each foo substack contains an object to distinguish the stacks from one another, so I can tell which foo stack is which at a glance.
>>
>> With that prep out of the way, I began my experiment:
>>
>>
>> Experiment 1
>> ------------
>> I started a fresh session in LC, and opened tA.
>>
>> Then I opened tB.
>>
>> And since I'd commented out revCheckStackCollision, no warning was presented.
>>
>> So then in stack tA I clicked the button, and it opened the foo substack belonging to it.
>>
>> Then I clicked the button in stack tB, and it opened the foo substack belonging to it.
>>
>>
>> Experiment 2
>> ------------
>> I created a third stack file, and added a button with the same script as above.
>>
>> When clicked, it opens the foo window belonging to the stack file which had been opened first.
>>
>>
>>
>> Results
>> -------
>> It would appear that the resolution of substack names follows a logical path that looks for matching stacks in this order:
>>
>> 1. Within the same stack file as the script referring to it.
>>
>> 2. Within another stack file, in the order in which they were opened during the session.
>>
>> This seems more or less what I've been hoping to find for years:
>> http://quality.livecode.com/show_bug.cgi?id=1061
>>
>> Unless there's something here that I've missed, it would appear that stack name resolution is nearly as logical and useful across stack files as icon ID resolution.
>>
>> And just as we don't need to go through contortions to ensure that every icon ID is unique across all stacks, as long as we remember the resolution rule we can safely use stacks of the same name within the current session.
>>
>> That is, once we modify the IDE to allow it.
>>
>> Is there something I've missed here?
>>
>> --
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com                http://www.FourthWorld.com