[Harmony proxies] Opinion on the open issue (How to deal with inconsistent data returned by handler traps?)
Tom Van Cutsem
tomvc.be at gmail.com
Tue Mar 22 05:12:12 PDT 2011
2011/3/18 David Bruant <bruant at enseirb-matmeca.fr>
> Le 16/03/2011 10:25, Tom Van Cutsem a écrit :
> This open issue is indeed one that merits further discussion here.
> Some thoughts and comments:
> * I think we did come to an agreement that custom property attributes were
> seen as very useful for communicating new kinds of meta-data about objects,
> and that they ought to be preserved. See also this bug: <
> That would solve one of the issues you raise.
> Ok. I'll follow on the bug.
> However, from what I understand, it (and the current Object.defineProperty
> semantics) does not fully let the user to define his/her attributes names
> and semantics.
> In the proxy semantics strawman, Object.defineProperty step 3:
> "Let desc be the result of calling ToPropertyDescriptor with Attributes as
> the argument."
> The /ToPropertyDescriptor/ call normalizes 'configurable', 'enumerable',
> 'writable' to booleans and throw if 'get' or 'set' isn't callable. This
> prevents people from passing differently typed values.
Right, this is following the current ES5 semantics of Object.defineProperty.
> I think we need the other communication side too. [[GetOwnProperty]] calls
> /ToCompletePropertyDescriptor/ which also calls /ToPropertyDescriptor/. So
> if I want to use a different type for the usual attribute names (which, in
> my opinion, are common names), I cannot. Moreover, the property descriptors
> returned by Object.getOwnPropertyDescriptor are forced to have an
> 'enumerable' and 'configurable' property (and others depending on data or
> accessor descriptor). If I want to decide my own attributes&semantics and do
> not care about the "forced" one, then I am paying a performance/semantics
> overhead for no obvious reason. This can be annoying if I want to return a
> proxy as the property descriptor or if I want to iterate over property
> attributes through a for-in loop or Object.getOwnPropertyNames+Array method
> (forEach, every, reduce...).
> What is your position on this point? Is there also a bug number for this
There is no bug report for this as far as I can tell. I have no strong
opinion on the coercion of standard property attributes. Coercing is closest
to the current ES5 behavior, though. Also, I'm not convinced that
programmers should be able to redefine the meaning of the standard property
attributes. The standard attributes have a well-defined meaning, and they
are an implicit part of the
Object.defineProperty/getOwnPropertyDescriptor/... API. Won't redefining
their semantics be needlessly confusing?
* The place where argument/return value validation is most critical is where
> fundamental traps are called by the runtime itself, not by client code,
> because of a missing derived trap. The question here is: how should the
> default implementation of a derived trap deal with inconsistent data
> returned by the fundamental trap on which it relies?
> The way I see it, default implementations of derived traps are just a
> convenience. In my opinion, they should be the exact reflection of their
> related ECMAScript object method/internal method and not do more data
> validation/formatting than these do.
> As a convenience, proxy programmers should be aware of limitations and
> conventions in default implementation expectations. We can document them, it
> won't be hard at all.
> And if programmers decide to not respect the conventions in what they
> return from their fundamental traps, then they are exposing themselves to
> inconsistencies. Either they accept it and consider that as feature and not
> bug or they can always implement derived traps if they aren't satisfied with
> how the default derived trap behaves.
> No matter what is decided for derived traps default implementations
> (current spec, current spec + data validation/formatting, other spec), there
> are going to be people for which this doesn't fit their use cases, so they
> will have to re-implement them. So I would be in favor of having default
> implementations which are consistent with ES objects behavior and perform no
> further checks (which will also improve performance).
> I would like to point out that internal data validation/massaging is always
> surprising from the programming/debugging point of view. A programmer
> doesn't always know the restrictions ("I returned duplicates in the
> get(Own)PropertyNames trap and they've been removed! How so?", etc.)
I fully agree. On the other hand, it may be equally surprising for a
programmer to find out that Object.getOwnPropertyNames(obj) may contain
duplicate property names. It's not clear to me which side is more important.
However, there will probably be much more "client code" using proxies than
code creating proxies.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss