Rugged ID

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Rugged ID

Post by monte » Thu Jun 20, 2013 4:14 am

mwieder wrote:@Monte- LOL. I mean backward-compatible from here forward. If we implement some interim solution now then we're probably stuck with it. Even if it gets deprecated I don't see it going away, and then we've got at least two different formats. If we really *do* want an interim solution and then move to something more permanent later on, why not use uuids as ids for an interim thing?
Right, I think this is @runrevmark's point. Because he knows what's coming he can connect dots that we don't know are there. I did really like the idea that we ended up with that would allow current object references to just keep being used and newly created objects to be uuid based so there wouldn't be any conflicts or any need for translations... everything would just work... apart from saving as an old stack file format ;-(
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Rugged ID

Post by mwieder » Thu Jun 20, 2013 5:15 am

Because he knows what's coming he can connect dots that we don't know are there
LOL. They try to tell me that about the government, too.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1209
Joined: Thu Apr 11, 2013 11:27 am

Re: Rugged ID

Post by LCMark » Thu Jun 20, 2013 10:15 am

Because he knows what's coming he can connect dots that we don't know are there.
This is true to a certain degree at the moment.

My overriding sense here is that right now we need to solve the VCS problem, so let's do that. It is quite a specific problem, its domain is entirely IDE focused and its function should be entirely transparent to user scripts (in the usual course of things - I realize custom control related activities need to be aware of the potential existence of lcVCS in the current scheme).

The refactoring project is moving apace and it won't be too long before that becomes the engine on which further features will be built - that is the point to start looking at how to improve the control reference situation. The current 'id becomes uuid' proposal is incredibly scripter-visible, and I really do think there is a solution lurking which doesn't require its level of scripter-visibility (However, I don't discount uuid's as potentially being an 'implementation detail', something internal that supports transparent operation from the scripting point of view).

Anyway, in regards to the UUID for VCS, @monte already started a new topic on that so I'll post there shortly with some thoughts.

Locked

Return to “Engine Contributors”