Hi. Not filtering, just too busy to do more than skim.

On Mon, Oct 1, 2012 at 5:40 PM, Brendan Eich <bren...@mozilla.org> wrote:

> Norbert Lindenberg wrote:
>
>> >>>>  3) The state mentioned in 2) is modifiable.
>>>>>> >>>>  >>>>  True for some ES5 objects (Array, Date, RegExp),
>>>>>>
>>>>> >>>  Don't forget Object:-P.
>>>>>
>>>> >>  >>  I'm thinking of state that goes beyond an empty object and
>>>> makes a BuiltIn instance function as a BuiltIn instance. Object instances
>>>> have no such state.
>>>>
>>> >  >  Can Arrays? Remember, 'length' is observable just a data property
>>> and the custom [[DefineOwnProperty]] or [[Put]] hook is not state.
>>>
>>
>> length is part of the state, but you're right, sometimes it takes more
>> than state and visible methods.
>>
>
> To be concrete, 'length' on an Array instance can be frozen (modulo
> implementation bugs to be fixed).
>
> The issue is really mutable state hidden from Object.freeze. Mark will I'm
> sure confirm (and I'm sorry for filling his inbox!). Array is not a problem
> in this light. Glad to hear Intl.Collator isn't either.


The security issue is primordial state that can't be made deeply immutable
with freeze, such as ES5 Date.prototype, FF WeakMap.prototype, or the
non-standard, non-deletable RegExp statics implemented by several browsers.
Array.prototype being an array is unfortunate, but so long
as Object.freeze(Array.prototype) works correctly, it's not a security
problem.  For new buildins and classes, I agree that constructor.prototype
should be an object with the conventional class-inheritance-like wiring
(constructor.prototype.constructor === constructor,
constructor.prototype.[[Prototype]] == superconstructor.prototype). Classes
should not try to make prototypes which are prototypical instances in any
sense.

Regarding the integrity of original Object.prototype.toString.call as a
branding mechanism, I agree we need a new more general branding mechanism.
WeakMaps and Symbols both give us a place to hang this, but we need a
concrete proposal. The proposal should work both with builtins and with
classes. If a better branding proposal waits till ES7, then we need to
preserve integrity of original Object.prototype.toString.call as a branding
mechanism through ES6. If this is preserved through ES6, then it probably
becomes too entrenched to consider retiring.

Were there other questions for me that I missed?


>
>
> /be
>



-- 
    Cheers,
    --MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to