Object ID's
Neil Mix
nmix at pandora.com
Fri Mar 16 23:58:15 PDT 2007
On Mar 16, 2007, at 4:23 AM, Lars T Hansen wrote:
> IMO we'd be better off following Java here and just spell out (more)
> clearly that you can't use the hash code as an object ID. The purpose
> of intrinsic::hashcode is after all to allow fast object-identity
> hashing. The use case for object IDs seems less clear.
Here's my problem: if one doesn't understanding the context behind
intrinsic::hashcode, it looks like a bug:
var key = new Widget(); // our unique lookup "key"
var val = new Acme(); // value to reference
var hash = {}; // our "hash table"
var keycode = hashcode(key); // our hash table key
hash[keycode] = val; // UNSAFE
I see from the discussion page that this may be tied into some sort
of dictionary datatype? I'm having trouble understanding the use
case for this otherwise. Sorry if I'm missing the point of this
feature, the context available in the docs is either missing or over
my head. :(
The use case that brought me to wondering about this was some vague
brainstorming about a generic data binding architecture. Given that
es4 has sealed objects, the only way to safely reference a dependent
object from its "data source" is to a) create a wrapper object (which
could get expensive) or b) use a lookup table.
But, there's no way in the current spec to use a sealed object as the
key in a table, unless you implement your own lookup mechanism that
accounts for collisions, but then again it seems a bit silly to
implement a hash table in JavaScript, doesn't it?
It's not a particularly strong use case, but my point is that if you
start from the position of wanting object A to reference object B,
but object A could be sealed, then there's no stupid-simple way to
set up the reference. (OTOH, for unsealed objects it's safe to
simply add B as a member of A, provided you DontEnum it, which is
awfully handy and simple.)
More information about the Es4-discuss
mailing list