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 >> id)". >> >> 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 working on.
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 your project.
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>).
-- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
