[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Wed Jun 15 08:43:22 PDT 2011


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


More information about the es-discuss mailing list