Stack name conflicts resolved?

[Monte Goulding]

> On 8 Nov. 2016, at 6:24 am, Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> > Using the long id to refer to stacks works (or at least should work)
> > for all situations except for stacks that haven't yet been saved to
> > disk. And for those stacks I would suggest storing the creation
> > timestamp as a custom property on creating a new stack so that they
> > can be distinguished.
> 
> A UUID in the v9 file format could help a lot with those cases.


Ah… I knew we would get onto UUIDs ;-)

One thing to note is if objects have UUIDs then there’s no need to qualify the UUID with an object type and the engine should just work out if the object reference is a UUID then look up the corresponding object. In other words we don’t need `the <prop> of stack UUID <UUID>` we just need `the <prop> of <UUID>`.

For most of the issues this thread is discussing though I actually don’t think the main thing we need is UUIDs. We *think* we need UUIDs only because we are used to thinking of object references as strings. If we have an object reference (think `is strictly an object`) and we have versions of all APIs that return object references that can return these object references instead then we have something much better because it won’t need to be parsed from string -> object all the time.

Now if we have a UUID as a string representation of the object reference that’s fine and probably helpful. There’s obviously times where you need to do stuff that will turn the object reference into a string.

Cheers

Monte