ID's are settable???
ambassador at fourthworld.com
Thu Jan 13 14:42:44 CST 2011
Bob Sneidar wrote:
> On Jan 13, 2011, at 9:46 AM, Richard Gaskin wrote:
>> Apparently you can set the ID of a stack to a higher number than
>> it currently is, but attempting to set it to a lower number will
>> generate an error stating "invalid id (must be greater than current
>> This is reasonable to expect given the stack's unique role as the
>> arbiter of IDs: as long as there's no internal list of all IDs
>> currently in use (and given the compact size of stack files I
>> certainly don't mind that there isn't), if you could set the stack
>> ID lower you would risk creating a new object whose ID would
>> conflict with an existing one.
> My personal opinion is that this is a bit of a kludge. Stacks should
> have their own unique ID like any other object, and internal objects
> should have their own unique ID inside each stack. The ID should be
> read only. If users want their own ID system, the AltID was a perfect
> solution for that. The ID counter could have been implemented as some
> kind of read only property of the stack. But that is all water under
> the bridge now.
Looks like we're looking at two different issues: I was describing the
limit on the ID range, and here you're covering the virtue of altID
instead of having settable IDs, and the absence of a true stack ID.
Yours is a more interesting topic, so let's go with that:
For settable IDs, Mark Wieder could make a stronger case than I could,
since this feature was added to support a nifty new tool he's been
Even though I don't use stack-to-text-and-back translators myself I can
see the value of them for some workflows. As wonderfully compact as the
binary stack format is, if you want to take advantage of existing
enterprise-level version control tools you'll need textual source for
Without being able to set the ID it would be impossible to accurately
reproduce an object. But with that, you should be able to make a
bit-for-bit copy of darn near anything, and the implications can be
quite powerfully useful if used with care.
As for it being a kludge that the stack ID is an incrementer rather than
an immutable reference that could be used like any other ID, for the
sake of consistency in the language I'd tend to agree, esp. given the
low cost of storing that integer in some other place.
I suspect it was one of those late-night decisions for Dr. Raney,
probably something that made his hashing scheme more convenient, and
since stack names serve as unique identifiers he probably felt that was
an okay design decision.
Weird, and one more anomaly that increases the angle of the learning
curve, but not the least of them (my favorite being "destroyStack" which
doesn't actually destroy the stack at all <g>).
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
More information about the use-livecode