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


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to