Le 15/06/2011 17:10, Brendan Eich a écrit :
On Jun 15, 2011, at 5:19 AM, David Bruant wrote:
Le 15/06/2011 13:34, Tom Van Cutsem a écrit :
(As an aside: re. the emulation of arrays, having a configurable
[[Class]] such that |Object.prototype.toString.call(arrayproxy)| can
return "[object Array]" seems like a more important imperfection to fix)
I disagree. People can fix this one by themselves:
https://gist.github.com/1026960 (I haven't tested, but it gives the
idea).
That's kind of gross, though.
I agree. My point was just to prove that it's possible. But it's gross
indeed. Moreover, my trick wouldn't work in an environment with several
globals (unless redifining all of them which is gross²)
Non-modular. Clearly Tom was talking about modular or proxy-wise
customization of [[ClassName]]. IIRC Allen has done work to separate
[[Class]] from [[ClassName]] which should allow proxies to intercede
for the latter.
I'm looking forward to see it coming.
Of course this solution is valid as long as observable side effects
of [[Class]] can be redefined.
This is not the case for the .length issue.
Can you give an example of the length issue? Sorry if I missed it.
Currently, one open issue is deciding whether
Object.get{Own}PropertyDescriptor should say that every proxy property
is configurable (the main pro argument is that it would prevent proxies
from lying by saying that properties aren't and change configuration or
removing at the same time).
Sean has a proposal to have some sort of "separate" records for
non-configurable properties on proxies, both guaranteeing
non-configurable invariants and the ability for proxies to have
non-configurable properties.
However, this proposal prevents from implementing arrays which have a
non-configurable "length" but have a special behavior (relationship with
numeric properties) that wouldn't be emulated by the "separate" records.
So basically, if an ES implementation had a bug on arrays .length
proxies may not be able to fix them.
My position on the open issue is that proxies should not try to enforce
configurable or enumerable since they just cannot.
I'm currently torn between two visions of ECMAScript objects. The former
is a property-based vision: an object is a collection of string -> value
associations. The latter is a Meta-Object Programming contract-based
(MOP) vision. This second vision is more general and can modelize the
former by enforcing invariants and relationship between internal methods
(https://github.com/DavidBruant/PropStackObjects was an experiment in
that direction). I think it's nothing less than a classic
data/computation point of view difference, but considering one or the
other changes the vision on proxies. In the former, Sean's proposal
makes sense. I'm more doubtful on the latter because (in my opinion)
there is no reason to isolate the behavior of some inputs of the MOP
contract methods.
And non-configurable invariants could be enforced on top of the latter
vision, the opposite is not true.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
