On Feb 13, 2013, at 12:53 PM, David Bruant wrote:
> Le 13/02/2013 20:36, Tom Van Cutsem a écrit :
>> Hi David,
>>
>> I went a bit too far suggesting frozen objects could de-facto disappear with
>> proxies.
>> I'm still unclear on the need for specific seal/freeze/isSealed/isFrozen
>> traps
>>
>> I think Allen and I reached consensus that we might do without those traps.
> Excellent!
Where "do without", means replaced with set/getIntegrity traps and objects
have explicit internal state whose value is one of
normal/non-extensible/sealed/frozen (and possibly) "fixed-inheritance"
between normal and non-extensible to freeze [[Prototype]]).
[[SetIntegrity]] can increase the integrity level but not decrease it.
The perf and invariant complexity concerns come from the fact that the
sealed/frozen status of an object can only be inferred by inspecting all of its
methods. Having an explicit state eliminates the need to do this inspection.
It also simplifies the MOP by merging all of the extensible/sealed/frozen
related MOP operations into only two ops. But, one way or another, these
object state transitions must be accounted for in the MOP.
For this to fly, implementation have to be able to expand their current 1 bit
of of extensible state to at least 2 bits (3 would be better). Or perhaps not,
I suppose we could just introduce the MOP level changes and a lazy
implementation could continue to infer the state by examining all its methods.
>
>> In addition, Allen was considering an alternative design where the "state"
>> of an object (i.e. "extensible", "non-extensible", "sealed" or "frozen") is
>> represented explicitly as an internal property, so that Object.isFrozen and
>> Object.isSealed must not "derive" the state of an object from its properties.
> Interesting.
> So what would happen when calling Object.isFrozen on a proxy? Would
> Object.isFrozen/isSealed/isExtensible reach out directly to the target? or a
> unique "state" trap returning a string for all of them? ("state" is too
> generic of a name, but you get the idea)
This is a question regarding proxy design, rather than the MOP. Either
get/setIntegrity traps to the handler or it forwards directly to the target.
That's would be a design issue for Tom, but my starting point is to simply
follow the current design decisions made for
[[PreventExtensions]]/[[IsExtensible]]
>
> Regardless on the final decision on (full) notification proxies, maybe these
> operations (isSealed/isFrozen) could have notification trap. The invariant is
> that the answer has to be the target one (all the time), so the trap return
> value is irrelevant. Like the getPrototypeOf trap.
Right, one way or another these operations need to be part of the MOP.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
