2013/5/24 Tab Atkins Jr. <[email protected]> > 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. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
