Minor type confusion in proxies proposal?

Tom Van Cutsem tomvc.be at gmail.com
Sat Jul 2 05:09:09 PDT 2011


2011/7/2 Mark S. Miller <erights at google.com>

>
>
> On Fri, Jul 1, 2011 at 2:55 PM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote:
>>
>> > In our implementation we are using a generic object. It has some
>> overhead, and a specific internal "descriptor object" representation might
>> be a bit faster, but such magic objects that don't allow expando properties
>> are usually pretty surprising to programers. Most of the HTML5 DOM allows
>> arbitrary expando properties. I think we should stick to that theme.
>>
>> IIRC Tom and Mark's http://traitsjs.org/ work relies on being able to
>> extend property descriptors with .required and other ad-hoc ("expando")
>> properties. This is important: it allows developers to blaze trails and
>> tread paths that we later pave with standards.
>>
>
> These are present in the user visible descriptor objects, but traits.js
> does not assume they are preserved in the internal descriptors. It can't
> assume that, since trait.js works on current ES5 browsers whose internal
> descriptors don't. Maybe Tom has thought about it, but we haven't discussed
> how this change would effect traits.js. My guess it is would have a positive
> effect. Tom?
>

Indeed, traits.js can get by without requiring non-standard attributes to be
"interned". However, part of the reason why we could get away with this is
because we could roughly "encode" the semantics of properties marked
"required: true" and "conflict: true" in terms of standard attributes. For
example, a property marked as "required: true" indicates an "abstract"
property that should be invisible on a trait instance. We encoded such a
property as an "enumerable: false, value: undefined" data property, to make
it as invisible as possible in practice (yet the in-operator or the
introspective Object.* methods would still reveal it).

With proxies that relay non-standard attributes, one would have the option
to encode trait instances as proxies that can retain and enforce all trait
semantics. For traits.js in particular, we wouldn't actually encode trait
instances as proxies as our encoding happens to be sufficient for practical
needs. But as David's experiment shows, who knows what attributes developers
will come up with, and what semantics they will want to associate with those
attributes.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110702/9fbe3a1e/attachment.html>


More information about the es-discuss mailing list