Non-generic traps for non-generic objects
brendan at mozilla.com
Fri May 24 22:10:17 PDT 2013
Tab Atkins Jr. wrote:
> As I've argued and demonstrated in these threads already, no, you
> can't just do it yourself. Every solution fails in at least some
> details, usually trading security against convenience or the other way
Enough rhetoric! It's not as if everything is equally bad.
Andreas made the case against subclassing by pointing out key
Tom previously showed how to compose with a proxy, without hardcoding
the set of Map methods. The only objection you had then was to Tom's
statement that there's a trade-off between integrity and forward
compatibility, specifically should anyone add a Map method that needs to
be overridden to prevent its Map implementation from bypassing the
integrity constraints using internal (private state) magic.
You originally wanted base-level traps for the internal (private state)
magic, but who is to say that such traps won't change in the future?
Your spec won't fail to "compile" if it is not updated to track the trap
changes. Someone will need to track and update the spec.
(Anyway, we're not adding more base-level traps all over the place on
this kind of claim-jumping non-argument.)
So what was wrong with Tom's proposal (extended to trap get, to handle
method extraction [funargs]), compared to any realistic alternative?
> This isn't acceptable, given that I can produce a*perfect*
> "object map" with existing Proxy operations.
But you want a Map-like API to avoid key vs. method-name conflicts. So
you have to worry about method integrity and forward compatibility.
There is no way to be future-proof against arbitrary changes to Map
internals that the new class might rely upon, whether implicitly or
explicitly. Your spec could get stale no matter what. No spec or
programming language provides perfect forward compatibility on this point.
(True, you could argue the Map internals are more likely to be stable
than the set of Map methods. But who knows? Murphy was an optimist.
Arguing one way for the internals, another for the externals, is not
The best you could hope for with a programming language would be a
(typically link-time) error. Where's that spec linker when you need it? :-P
Anyway, as I wrote above, I think you protest too much. Tom's solution
is more than enough. I'd just keep an eye on Map's methods and avoid the
More information about the es-discuss