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 ;-(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?
Rugged ID
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: Rugged ID
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Rugged ID
LOL. They try to tell me that about the government, too.Because he knows what's coming he can connect dots that we don't know are there
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Rugged ID
This is true to a certain degree at the moment.Because he knows what's coming he can connect dots that we don't know are there.
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.