[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Fri Jun 17 11:56:01 PDT 2011

Le 17/06/2011 18:45, Mark S. Miller a écrit :
>     What is the rational behind each of these?
> One of JavaScript's great virtues is that it is a highly reflective
> language, leading programmers and framework builders to engage in a
> wide range of meta-programming patterns. One of JavaScript's great
> flaws is that its property state space is complex, leading such
> meta-programmers into a case explosion. Prior to ES5, there were so
> few guarantees of any stability properties over this state space,
> especially for non-native ("host") objects, that robust programming
> was almost impossible. 
> For example, Caja on ES3, to uphold its own invariants, must handle
> non-native objects very carefully. (...). To diminish the cases we
> need to worry about, Caja pays substantial costs to ensure that
> untrusted code never gets a direct reference to any non-native object,
> not even "alert". This ice is too thin.
It may be a naive question, but why should untrusted code be prevented
from getting a reference to a non-native object? Do you have a concrete
example of threat this protects from?
... well... if untrusted code has access to "alert", it can do "while(1)
alert();" and prevent trusted code from running. But all other
non-native objects?

How did each of the 4 "Universal property constraints" made Caja's work

For NodeLists proxy emulation, the "length" property cannot be changed
manually (as far as I know), so I'd say that its writable has to be
false (tell me if I'm wrong to think that). The "length" value can
however change due to DOM tree transformations. For this reason,
configurable has to be true as per Universal property constraints 1) a).
However you cannot really configure it in the sense that you can't
neither delete it nor re-configure it. "configurable" does not really
mean that the property is configurable (not quote) on host objects.

I'm just puzzled by the wording I think. "configurable:true" on normal
native objects means "this property is configurable (delete +
Object.defineProperty with any property descriptor)".
However, for abnormal+non-native objects, the semantics of
"configurable" is constrainted to the Universal property constraints,
but does not give any insight on what you can do with the property.
Exact semantics (what you can do with the property) is left at the
discretion of the object implementor.
The confusing part for me is probably the "-able" suffix which sounds
like giving me an information on what I can do with the property (like
"enumerable" do), but this is actually not the case at all for
abnormal+non-native objects. It's not that big of a deal for abnormal
native objects since I can read the spec to know what to expect from these.

On a last note, array.length already do respect all Universal property
constraints since writable is true. Or am I missing something?

Thanks for your explanations,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110617/03f2703d/attachment-0001.html>

More information about the es-discuss mailing list