... and while it might be unclear from my tone, I've repeatedly hit pain points weak references, so I'm for an encoding getting in. It's a big deal for proper frameworks & DSL design.
The dictionary approach was nice in that it supports weak references (a singleton collection) and provides object->value mapping in one small API, but from a semantics / design perspective, it's not very orthogonal. E.g., a weak reference option and an actual object->value dictionary can be used to create a weak dictionary with an equally (asymptotically, at least) sized heap. - Leo On Jul 3, 2010, at 11:34 PM, Leo Meyerovich wrote: > > On Jul 3, 2010, at 10:50 PM, Mark S. Miller wrote: > >> On Sat, Jul 3, 2010 at 10:27 PM, Leo Meyerovich <[email protected]> wrote: >> Is object identity the inverse of hash? So myObj == identity(hash(myObj))? >> >> No. There is not and must not be an identity function which turns data into >> access. This would destroy the most important safety property of JavaScript, >> that object references are not forgeable. >> > > > I'm with you there. Was surprised when I thought it was being proposed in > that way! > > >> Also, hashes can collide. So the most you get is the conventional: >> >> * if (typeof x !== 'number' && x === y) then hash(x) === hash(y) >> >> * if (hash(x) === hash(y)) then it is likely but not guaranteed that x === y. >> > > Object hashes seems like a misnomer in this case as it seems fine to require > them not to collide. I don't know what happens in JS when you use more than > 32 bits or 64 bits of references, but I'd expect a similar out-of-memory > restriction for a for-free (hashless) implementation ;-) Anyways, red herring > and I probably don't know enough about serialization, object persistence, > etc. to discuss what a useful API would be here for expected use case in a > helpful way. > >> >> Then weakly keyed or mapped tables are obviously possible, even though >> they'll have to be manually cleared of expired values. >> >> Unfortunately, while this may support encoding weak mappings, I suspect a >> feature like that is used more often in frameworks than application code, so >> there might be a big penalty. ActionScript 3 introduced a Dictionary object >> that performs weak mappings -- perhaps that can be used to find a concrete >> comparison point. i don't know how this is distinct from 'ephemeron' tables, >> so I might be missing something. >> >> I don't know ActionScript or its Dictionaries. > > http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html > > I no longer have asc installed so cannot directly check when they write > 'weakKeys' whether they really meant weak keys or weak mappings (so both key > & value are weak); the description reads both ways. It might be useful to > analyze how it is used (or not) before suggesting a deviation from it. This > is not from the perspective of weak dictionaries being good but something > that can be learned from. > > FWIW, I believe ActionScript's use introduces non-determinism to the > language: iterating over the dictionary can reveal an object that is only > weakly referenced if the GC hasn't run yet. At this point, the JS semantics > guys might want to chime in -- it simplifies requirements on GC > implementation, but I don't know how it changes program analysis (e.g., an > escape analysis would simply be conservative there). Just as introducing > forgeable references breaks encapsulated reasoning, this might also interact > oddly with some useful characterizations of JS. Unfortunately, the > semantically clean alternative, forcing a reachability check, isn't decidable. > > - Leo > > > >> >> >> - Leo >> >> >> >> On Jul 3, 2010, at 12:00 PM, [email protected] wrote: >> >>> Send es-discuss mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://mail.mozilla.org/listinfo/es-discuss >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of es-discuss digest..." >>> Today's Topics: >>> >>> 1. Re: We need to name "EphemeronTable" (was: Do we need an >>> experimental extension naming convention?) (Brendan Eich) >>> 2. Re: We need to name "EphemeronTable" (was: Do we need an >>> experimental extension naming convention?) (P T Withington) >>> >>> From: Brendan Eich <[email protected]> >>> Date: July 2, 2010 10:01:26 PM PDT >>> To: Mark S. Miller <[email protected]> >>> Cc: "[email protected]" <[email protected]>, Erik Arvidsson >>> <[email protected]> >>> Subject: Re: We need to name "EphemeronTable" (was: Do we need an >>> experimental extension naming convention?) >>> >>> >>> On Jul 2, 2010, at 7:45 PM, Mark S. Miller wrote: >>> >>>> I'm also in favour of a regular Map and Set. Also a dense List (i.e., what >>>> we might have otherwise called an Array :(.) However, the history of oo >>>> class libraries shows collection libraries to be a tarpit, so I'm >>>> unwilling to take the lead on this issue. If someone else would like to, >>>> so long as they keep it bloody simple (i.e., not like Java, Smalltalk, or >>>> STL), that'd be great. Even the E collections >>>> <http://erights.org/elang/collect/tables.html> >>>> <http://erights.org/javadoc/org/erights/e/elib/tables/EMap.html>, where I >>>> could make them as simple as I wished, got way too complicated -- more >>>> complicated than I would find acceptable. >>>> >>>> Great designers of extraordinarily simple expressive APIs, please step >>>> forward! >>> >>> Ideally TC39 should not standardize or design anything not already proven >>> and popular (if not dominant) in the field. The problem is no one can make >>> practicaly O(1) collections without Object.hashcode and Object.identity. >>> >>> Say we add hashcode and identity. Then we'll have to wait a while, Could we >>> bootstrap Set, Map, and WeakMap and call it enough? I think so. >>> >>> "Dense List" could be added but implementations are optimizing for dense >>> arrays already. I think this one is too close to Array to be worth it, but >>> without a detailed design that's just my gut reaction. FWIW. >>> >>> /be >>> >>> >>> >>> From: P T Withington <[email protected]> >>> Date: July 3, 2010 4:47:50 AM PDT >>> To: Brendan Eich <[email protected]> >>> Cc: "Mark S. Miller" <[email protected]>, Erik Arvidsson >>> <[email protected]>, "[email protected]" >>> <[email protected]> >>> Subject: Re: We need to name "EphemeronTable" (was: Do we need an >>> experimental extension naming convention?) >>> >>> >>> Coming late to the party: 'alias' might be intuitive (from it's dictionary >>> definition and use in filesystems as a non-preserving way to give an >>> alternate name). >>> >>> On 2010-07-03, at 00:57, Brendan Eich wrote: >>> >>>> On Jul 2, 2010, at 8:58 PM, David Herman wrote: >>>> >>>>>> Cool. I'm warming to WeakMap as well. Do we have any objections to >>>>>> WeakMap? >>>>> >>>>> +1 >>>>> >>>>> I <3 WeakMap. >>>> >>>> The Force is strong with WeakMap! ;-) >>>> >>>> +1 or more >>>> >>>> /be >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> -- >> Cheers, >> --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
