ID's are settable???

[Richard Gaskin]

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