Object ID's are simply a way for the software to uniquely identify an
object. That the ID is made visible to the programmer seems to me to
be a convenience. Since you can refer to an object by name anyway,
there really is no hard fast reason to refer to it by it's ID. It
would be like deleting a user profile in Windows, then creating
another and giving it the same ID. Hey, actually that would be cool!
But I digress.
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
On Dec 9, 2008, at 2:01 PM, [EMAIL PROTECTED] wrote:
In a message dated 12/9/08 3:08:11 PM, [EMAIL PROTECTED] writes:
To add to what Bjornke posted, if I delete a button and then want to
recreate it (as in a version control storage and retrieval system),
then there is *no way* to reuse its previous id in that stack. The id
number is lost to history. The only workaround for this is too ugly
to
discuss in mixed company.
There was a corollary debate in HC years back; whether the id should
be a
settable property. It was decided (very) on high that it would not
be. The
reasons are lost in time, but I recall it was felt that id's were
not intended to be
indexed, and that as permanent and unique as they were, id's also
needed to
die off completely if the object was deleted. A tribute, in fact, to
their very
uniqueness. In no way linkable, by design, to any remaining or future
objects.
And I would love to talk about a workaround. Perhaps remember the
old id,
linking it via a look-up table to some other object? But as before,
nobody could
think of a good reason to do so, that is, there was no value in
knowing that a
deleted id was either linked to or owned by any other object.
Numbers were
cheap back in those days, and the simple fact that every object had
a unique one
was considered more than sufficient.
**************
Make your life easier with
all your friends, email, and favorite sites in one place. Try it now.
(http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&ncid=emlcntaolcom00000010
)
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
