Stack name conflicts resolved?

[Ben Rubinstein]

Hi Richard,

No overtones intended by use of word "trying"! I should have said 
"experimenting with" or similar...

I am interested though that you noted, if I understood correctly, that your 
experiment showed that having two substacks with the same name didn't cause an 
issue in the IDE when using the substack name with "toplevel". QC #143 
suggests that (way) back in the day, there were serious issues that arose in 
this situation when attempting to save changes to such stacks. Did you find 
any evidence that this is still a problem?

best wishes,

Ben

On 07/11/2016 15:00, Richard Gaskin wrote:
> Ben Rubinstein wrote:
>
>> Currently if I understand it correctly there are issues which seem
>> just too hard to fix: so instead
>> http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious
>> of these issues - was 'fixed' by adding the check that Richard's
>> trying to remove.
>
> In all fairness, I'm not *trying* to remove it, but have in fact removed it -
> in my own copy of the IDE.
>
> As I noted in this post, I've not closed #1061 because I recognize that the
> IDE has different responsibilities beyond those of our own apps:
> http://lists.runrev.com/pipermail/use-livecode/2016-November/232451.html
>
> I'm just glad to find that the rule for looking up stacks by name built into
> the engine is simple, understandable, and very useful.
>
> We can have confidence that our standalones, which don't include IDE-specific
> code, will allow stacks of the same name to run without issue according to a
> fairly simple search rule.
>
> This means that I can have a classroom of students sharing stacks without
> having to impose all sorts of complicated schemes to ensure that stack names
> are unique.
>
> For standalones, the engine behavior is beautifully elegant.
>
> But I do recognize that the IDE has a special role with special
> responsibilities, and have left my original enhancement request open as we
> explore ways to address that, hopefully arriving at a middle ground which
> provides confidence about which stack we're working on while also giving us
> the freedom to use stacks as easily as the engine allows.
>