Michael Lazzaro:
# 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.
Generating the Ids on request (i.e. the first time you call .id) would
help, but it would still mean having a slot for the information.
Honestly, I think a unique-across-the-object's-lifetime ID is probably
fine for many purposes. Perhaps we could have a sort of weak reference
that would null itself out when its referent was destroyed, if this is a
problem. (Don't know how that would work with the whole immutable hash
keys thing, though...)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
