[Harmony proxies] Opinion on the open issue (How to deal with inconsistent data returned by handler traps?)

David Bruant david.bruant at labri.fr
Wed Mar 23 14:44:30 PDT 2011


Le 22/03/2011 23:09, Brendan Eich a écrit :
> On Mar 22, 2011, at 11:04 AM, David Bruant wrote:
>
>> I wouldn't argue if we had: Object.defineDataProperty(o, name,
>> enumerable, configurable, writable, value) and
>> Object.defineAccessorProperty(...). Or one Object.defineProperty with
>> ten arguments. But this is not the case.
>> I think that part of the reason why the commitee has agreed on an
>> object rather than another solution is to have the liberty of
>> providing different flavors (there are currently two with data and
>> accessor, maybe a third will show up eventually) and different
>> attributes one day or another. (Can someone from TC39 can provide
>> insights on the property attribute API design?)
>
> This has already been discussed, and indeed written up as a rationale
> document:
>
> http://www.mail-archive.com/es4-discuss@mozilla.org/msg02308.html
> http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf
> <http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1:es3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methods.pdf>
Thank you, that's a very interesting document and thread.
After reading, I feel that the potential of adding other attributes
wasn't part of the decision design. I was wrong. Still, the potential is
here.


>> Based on this rationale, I think that since proxies have the
>> potential entirely redefine their internal consistency, it could make
>> sense to completely forget about usual semantics of attributes. This
>> actually could be an interesting way to drive innovation and maybe
>> that relevant property attribute semantics patterns made by library
>> authors could eventually be added to the spec.
>
> Maybe, but should we be strict and explicit, or loose and implicit, in
> our interpretation and handling of the currently-spec'ed attributes?
In the spec, for regular (non-proxy) objects, the interpretation and
handling of currently-spec'ed attribute is and should be strict and
explicit, I agree.
For proxy-based objects, our ("we" means "spec writers") interpretation
and handling of currently-spec'ed attribute is non-existent, because as
soon as we leave the power of a function to a proxy author (for
'defineProperty' and 'getOwnPropertyDescriptor' traps), we allow them to
choose if they want to consider using "configurable" or "enumerable" or
not. For instance, we have no way to enforce consistency between calls
to Object.defineProperty ("enumerable" attribute value) and Object.keys.
I mean, we could enforce consistency here, but if we do, then
Object.keys isn't a trap anymore, or at least its return value wouldn't
mean anything. Object.keys would just be the function we know.
In a proxy-based object, properties created as non-configurable could be
deleted. Once again, you have no way to enforce that the property isn't
deletable.
My point is, you may provide any sort of changes to property
descriptors, but it doesn't impose anything on how the trap code will
interpret it. It's not because the spec defines the semantics of some
attributes that proxy authors will follow the spec.

There is also a potential for future backward incompatibility. If I
define my own attribute for my own proxy-based objects, let's say
"deletable", that I use to separate the concerns of deletion and
configuration. If one day, the ECMAScript standard standardizes the
attribute and provide a different default value, then all the people who
relied on my default value will see there code broken, since from the
trap, I won't be able to see the difference between an attribute defined
or omitted by a user or an attribute added by the engine before my trap
code is called.
So, either you take the risk to break a part of the web each time you
define a new attribute or you don't standardize it. Providing full
freedom on the attributes will allow both library authors and ECMAScript
specifiers to not fight each other when a new attribute keyword gets
defined in the spec.

I was about to say that since property descriptors are objects, proxies
could be used instead to fool the engine and pretend absorbing the
property defining ("enumerable", "configurable") calls, but denying them
within the trap. It turns out, the descriptor passed as an argument and
the object within the trap call aren't the same object (that's
consistent with ES5 and I understand this decision), so my idea falls apart.


> I think we will do better with strict and explicit, even as we allow
> libraries (such as Mark and Tom's http://traitsjs.org/ library) to
> extend property descriptors.
>
>
>>> Won't redefining their semantics be needlessly confusing?
>> I cannot answer that question. It will depend on people. For the
>> comparison, I would ask:
>> How confusing would it be if a host objects redefined property
>> attribute semantics? I'm going to provide a response below.
>
> In the last 15 years, host objects have been strange enough that the
> phrase "host object" is a malediction in 43 languages ;-).  Let's not
> add loose/implicit opportunities for strangeness.
>
> Sure, let's hope library authors add new and different extensions, and
> may the least-strange or most-beautiful win, and indeed feed into
> future standard editions.
>
>
>> About the surprising aspect, I am going to take the example of an
>> host object: NodeLists. NodeLists (returned by
>> document.getElementsByTagName() ) are live objects. It means that
>> once you have created it, it stays in sync with the DOM tree without
>> the programmer having to refresh the object in any way. This behavior
>> cannot be provided by any regular object. So programmers could
>> something equivalent to:
>> ---
>> var divs = document.getElementsByTagName('div');
>> for(var i; i< divs.length ; i++){
>>     document.appendChild( divs[i].cloneNode );
>> }
>> ---
>
> That's right, NodeLists are live and therefore must be implemented by
> Proxies in a self-hosted DOM. Coming soon at
>
> https://github.com/andreasgal/dom.js/
Awesome! Will be following that closely!


>> If you haven't loaded the module on purpose, well, I think that being
>> surprised by object behaviors may be the least of your concerns :-)
>
> Ok, but that's your opinion. If others disagree, they won't use the
> library. Over time a winnowing process will sort wheat from chaff.
>
>
> But this is *not* an argument for our core Harmony Proxies spec
> embracing strangeness by being loose or having implicit conversions, IMHO.
I'm sorry, I don't understand. What "implicit conversions" are you
talking about?
Just to make sure we are on the same page, the discussion we were having
was about turning property descriptor objects passed as
Object.defineProperty argument into a "classical" property descriptor
(data or accessor depending on what is already there) while inside the
defineProperty trap. This is an implicit conversion and this is what I
am against. So, what are the "implicit conversions" you are against?


>
>> I think I do not really understand what is inherently wrong with
>> "surprising" the programmer who has chosen to run your code. The
>> programmer who has chosen your library did it with
>
> (Your sentence ended prematurely there.)
... and I don't remember what I was going for :-s Sorry.


>
>> My opinion is that the Proxy API should encourage rich internal
>> consistencies as much as possible. And trying to keep consistency
>> with what we know of current regular objects interfers with that
>> vision. Once again, that's just my opinion, I don't mean to impose it
>> in any way. (I do not have any power to impose it anyway :-p ).
>
> I think this is a bad argument. Proxies (and of course host objects
> implemented in C++ or C) can do all sorts of strange things. This does
> not argue either that (a) proxies *should* be used to implement
> strange objects; (b) the semantics of proxies should be stranger than
> necessary by including implicit conversions.
Once again, I do not understand what "implicit conversions" you are
talking about.


Overall, one of the point I am rising is the definition of what is an
object. The ES5 definition says "An object is a collection of properties
and has a single prototype object. (...)" and each property is an
"association between a name and a value that is a part of an object.".
In my "PropStackObject" experiment
(http://davidbruant.github.com/PropStackObjects/ (view source)), I have
created a new object paradigm where a property is an association between
a name and a stack of values (in a nutshell, defineProperty and delete
allow to respectively stack up and pop up, while get and set only
manipulate the value on top of the stack).
When, in the defineProperty trap, I see a "configurable" attribute with
"false" as value, since I have changed the object paradigm, I have to
derive from spec semantics. That's where I said earlier that for
proxy-based objects, the interpretation and handling of currently
spec-ed attributes is inexistent. As I have a new paradigm, I have to
decide what "configurable" mean. Is the whole stack becoming non
configurable or just the last value? No matter how strict and explicit
the spec is, no one else but me has to make the decision. My preference
would be to not consider "configurable" at all for my "object paradigm".

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


More information about the es-discuss mailing list