On Dec 23, 2010, at 5:53 AM, Kevin Smith wrote:
> If I might ask a side-question: what's the value in making an object
> non-extensible in ES5? I understand the value of making properties
> non-configurable or non-writable, but I don't yet see a reason to prevent
> extensions.
Mark's answer brought up shared built-ins (primordials) but I don't think the
case of shared mutable primordials in a browser frame is necessary to argue for
Object.preventExtensions(). An extensible object O can be go wrong as follows:
Object detection patterns can be confused by party A extending O.P, party B
detecting ('P' in O) and wrongly assuming O has the P that B expects. In
general, an extensible object can be extended to spoof another object
(accidentally or on purpose), allowing the extended object to pass where it
should not pass.
ES5 strict mode error throwing helps here. This isn't just about security. In
developing any moderate amount of JS (e.g., Narcissus, in our experience), it's
too easy to have bugs where the wrong object is extended. Of course, I'm not
saying you can prevent extensions of all objects in such a codebase. Clearly,
some need to be extensible (at least for a while).
But the preventExtensions tool has its uses, and without it one has to insert
manual "type tests". Immutable ASTs and IR forms in compilers are a use-case
for freezing objects, as mentioned earlier (with some research pointers); these
also motivate weak maps.
/be
>
> Thanks!
> Kevin
>
>
> On Thu, Dec 23, 2010 at 3:18 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Dec 22, 2010, at 11:58 PM, Mark S. Miller wrote:
>
>> On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich <bren...@mozilla.com> wrote:
>> On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote:
>>
>> > Brendan, I still do not understand why you think it is illegitimate to
>> > consider private names and soft fields as alternatives. Do you really
>> > think we should provide syntactic support for both?
>>
>> The discussion here, including Dave's point about transposed get or set for
>> [] being conceptually mismatched to the current [] meaning, and
>> David-Sarah's reply about why you can't stop a third party from using your
>> frozen object identity as the key in a weak map, have convinced me that even
>> the frozen AST example doesn't need syntax, so much as weak maps and
>> whatever soft fields make sense on top of them as library code.
>>
>> I do not understand this reply. Could you expand?
>
> Dave wrote:
>
> "[O]verloading that syntax to mean lookup in a side table is what seems like
> a drastic break from the intuitive model of objects. I have nothing against
> side tables as a programming idiom; it's when you make them look like they
> aren't side tables that they become confusing. Especially when you can do
> counter-intuitive things like add new properties to a frozen object. Of
> course, there are clearly use cases where you want to associate new data with
> a frozen object, and convenience would be helpful. I'm just not convinced
> that making it look like ordinary object lookup is the right
> programmer-interface."
>
> David-Sarah wrote:
>
> "What's your intended goal in preventing 'adding' fields to [a frozen] object?
>
>
> If the goal is security or encapsulation, then freezing the object is
> sufficient. If I add the field in a side table, that does not affect your use
> of the object. I could do the same thing with aWeakMap.set(obj, value)."
>
> To answer David-Sarah's question, my goal in preventing "adding" fields to a
> frozen object depends on the syntax used to add those soft fields in exactly
> this way: aWeakMap.set(obj, value) is no problem, but (per Dave's words)
> obj[aSoftField] = value succeeding in spite of obj being frozen *is* a
> problem, conceptually for teachers, learners, documenters, hackers --
> everyone building a mental model of "objects and properties" including
> freezing.
>
> It seems you agree enough to be exploring @ instead of ., which could desugar
> to transposed .get or .set. So perhaps more new syntax will help, rather than
> less new syntax and too much overloading of old.
>
> /be
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
