Proposal: Abstract References

Claude Pache claude.pache at gmail.com
Mon Oct 27 14:21:40 PDT 2014


Le 27 oct. 2014 à 17:45, Mark S. Miller <erights at google.com> a écrit :

> On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg <rossberg at google.com> wrote:
> 
> Otherwise, we need to somehow recover the functionality we lost when we gave up the opt_useKeyLifetime flag. Given where we are, I propose another pair of weak-map & weak-set collections, with exactly the same contract as the current ones, except:
> 
> * The new weak collections would have no .clear method.
> * The hidden fields generated on the keys by the new weak collections would be expected to have their full key's lifetime, whether on not the key outlives the weak collection.

I propose to define something: 

* with a name that corresponds to the purpose; for example "HiddenField" instead of "WeakMap". Or even "PrivateField", which is in fact more restrictive than what you can get with a plain WeakMap (more below);
* with method names that agree with the transposed representation; maybe: `.getFrom()`, `.setFrom()`, `.deleteFrom()`. Compare:
	
	weakmap.get(key)

vs

	privatefield.getFrom(object)
	object::privatefield

Also, we must be careful not to consider WeakMaps as a way to achieve privacy (at least without wrapping the WeakMap). A map that holds weakly its key/value association without making the GC observable, must provide **hidenness** (you couldn't get a key/value pair if you don't have a prior reference to the key), but not **privacy**, as you can imagine methods on a weak map, such as `.clear()` or `.fill()`, that alter key/value pairs without mandating prior reference to keys and without making the GC observable.

—Claude


More information about the es-discuss mailing list