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

Brendan Eich brendan at mozilla.com
Tue Mar 22 15:09:07 PDT 2011


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


> 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?

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/


> Because of the live property, divs.length changes and this turns out to be an infinite loop. This is surprising to the programmer since live objects do not exist in ES3/5.

Some would call it a botch!


> What solves the surprise is that the programmer searches, discover the live property of NodeLists and fixes the bug. There is a surprise, it may be annoying, frustrating, but it doesn't last long.

It lasts long with some of us :-/.


> My opinion is that no matter what library you're loading and what crazy sort of proxies you're loading, these things will come with some documentation explaining differences with regular objects ("under such condition, we will return duplicate property names after a Object.getOwnPropertyNames call"). If the documentation is lacking, you still have the source code. In a way or another, the source of your surprise can find its cause.

And you can then choose to use a different and less surprising library.

Just pointing out that docs and open source don't make all strangeness palatable.


> When you choose a proxy library, you know it won't behave like regular objects. This is for the case where you purposefully import a library/module of some sort.

You may expect some strangeness from proxies, that is, some difference in behavior from regular objects, but you won't know what strangeness in particular (since even with proxies, never mind "host objects", there can be an endless and progressively stranger choice of strangeness).


> 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 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.)


> 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.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110322/2b4baec3/attachment.html>


More information about the es-discuss mailing list