Non-generic traps for non-generic objects

Brendan Eich 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
> around.

Enough rhetoric! It's not as if everything is equally bad.

Andreas made the case against subclassing by pointing out key 
contravariance.

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 
consistently skeptical.)

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 
proxy, myself.

/be


More information about the es-discuss mailing list