Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)
Tom Van Cutsem
tomvc.be at gmail.com
Sat May 25 01:28:37 PDT 2013
2013/5/24 Tab Atkins Jr. <jackalmage at gmail.com>
> What does the invoke trap do? It looks like it somehow covers the
> "p.foo()" case? Can it handle "var f = p.foo.bind(p); f();" as well?
> Just pointing me to docs would be sufficient, if they exist yet.
Given that invoke() was only just now considered, I can't point you at any
docs yet, but you got it right: invoke() handles the "p.foo()" case.
The example I posted can deal with "var f = p.foo.bind(p); f();" in the
sense that this too will throw with an "error: not a map" when trying to
apply one of the Map.prototype.* methods directly. If you want this to work
reliably instead of throwing, you can have the proxy implement the "get"
trap and have it return a bound function, binding |this| to the wrappedMap.
> So, this is pretty clever. It gives me most of what I want, which is
> better than any suggestion so far.
> The only bit I don't like is covered by your statement "You can't have
> it both ways: either you restrict the set of operations on your
> StringMap, which increases integrity, or you inherit an open-ended set
> of operations, which increases forward-compatibility.". In most
> languages, I *can* have it both ways, because maps are parametric by
> their very nature; the only difference between a string->string map
> and an object->object map is the type declaration.
Imagine we were doing all of this in Java: StringMap would be a class that
extends from a platform-provided Map class, and overrides the necessary
methods to add its own invariants. There's no need to use a wrapper because
one cannot circumvent the subclass methods. But even then so: who is to say
that my StringMap subclass remains safe when the JDK decides to add new
methods to the Map class that should also be overridden by StringMap to
enforce its additional constraints.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss