On 12/13/02 12:44 PM, Michael Lazzaro wrote: > On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: >> And I'd say (but who asked me -- IMHO, of course) that it should be >> perfectly valid to write code like the above. (That IDs should be >> unique across a process over all time.) If that'd require that an >> object's ID be a combination of the header address and a generation >> counter, that's OK. It means a serilization point in the allocator, >> but I think we'd need one no matter what (Dan?). > > I'm more worried about storing them than creating them. The good thing > about using memaddresses is that they're free; you don't need to store > a separate ID in each and every object you ever create, on the off > chance that something will want to use it. > > Having an actual internal ID associated with every object would mean > you'd have to store all those IDs, which could get very big very fast.
You could always just autovivify them. Since most objects will never have their "UUID"s accessed, the overhead should be very small. > I think the odds of you wanting a truly unique ID for any given class > are so low that we'd probably be better off leaving it as a DIY project. I think it's important enough to be in the "core", if only to prevent fragmentation in the world of object persistence. -John
