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 aperfect
"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.
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
Tab Atkins Jr. wrote:
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?
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.