2011/11/10 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 10, 2011, at 9:03 AM, Tom Van Cutsem wrote:
Regarding property deletion: if an object is implemented as a proxy, and
you would want to delete a property from that object, I'm not sure why you
would want to circumvent triggering the
2011/11/9 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 9, 2011, at 3:53 AM, Tom Van Cutsem wrote:
- lots of methods on Array.prototype (map, forEach, filter, some, reduce,
reduceRight, reverse, splice, indexOf, lastIndexOf, every, shift, slice,
sort, unshift): the only way in which these
2011/11/9 Allen Wirfs-Brock al...@wirfs-brock.com
[[Get]] seems to do nothing but redispatch to [[GetP]] so its definition
could be replaced with the body of [[GetP]].
[[Puit] does a redispatch to [[SetP]] followed by a mode based
conditional throw depending upon the result of the [[SetP]].
Le 10/11/2011 12:28, David Bruant a écrit :
(...)
but i think [traps] should be a right balance between the internal and
external API.
Internal object API:
* getPropertyDescriptor(propName)
* setPropertyDescriptor(propName, desc) (more or less equivalent to the
current [[DefineOwnProperty]])
On Nov 10, 2011, at 1:36 AM, Tom Van Cutsem wrote:
2011/11/9 Allen Wirfs-Brock al...@wirfs-brock.com
[[Get]] seems to do nothing but redispatch to [[GetP]] so its definition
could be replaced with the body of [[GetP]].
[[Puit] does a redispatch to [[SetP]] followed by a mode based
On Nov 10, 2011, at 1:26 AM, Tom Van Cutsem wrote:
Are you sure you want to kill [[HasProperty]] entirely? If we replace it by a
conditional [[Get]], wouldn't that mean that the expression |name in obj|
might unnecessarily trigger an accessor in obj?
Good point, I didn't think about
2011/11/10 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 10, 2011, at 1:36 AM, Tom Van Cutsem wrote:
- Object.getProperty and Object.setProperty built-ins that call
[[GetProperty]] and [[SetProperty]]
Also, to fully reify property manipulation I think we also need to factor
[[Delete]]
On Nov 10, 2011, at 3:28 AM, David Bruant wrote:
Le 09/11/2011 12:17, Tom Van Cutsem a écrit :
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
More generally, I think there should be a 1::1 correspondence between the
internal methods in listed in ES5 Table 8 and fundamental proxy
On Nov 10, 2011, at 9:03 AM, Tom Van Cutsem wrote:
2011/11/10 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 10, 2011, at 1:36 AM, Tom Van Cutsem wrote:
- Object.getProperty and Object.setProperty built-ins that call
[[GetProperty]] and [[SetProperty]]
Also, to fully reify property
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
I don't think that [[GetP]] and [[PutP]] need to be internal methods
In spec'ing this I think I would make them be abstract operations.
Internal methods are extensions points that can be over-ridden on a per
object basis. That is what [[Get]]
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote:
But I have a follow-up request. :) Regarding redundant trap calls with
proxies there is another, more pervasive problem with the current
spec: in lots of places it first calls
On Nov 9, 2011, at 3:53 AM, Tom Van Cutsem wrote:
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote:
But I have a follow-up request. :) Regarding redundant trap calls with
proxies there is another, more pervasive problem with the current
On Nov 9, 2011, at 3:17 AM, Tom Van Cutsem wrote:
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
I don't think that [[GetP]] and [[PutP]] need to be internal methods
In spec'ing this I think I would make them be abstract operations. Internal
methods are extensions points that can be
I am a big fan of this refactoring.
I like the idea that the algorithm transfers full control to the proxy.
Also, accepting this strawman would solve my inherited event properties
problem because I would have access to the receiver from the get trap
and would be able to do the binding I
On 7 November 2011 16:54, Tom Van Cutsem tomvc...@gmail.com wrote:
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way
in which these algorithms climb the prototype
chain:
Le 08/11/2011 11:54, Tom Van Cutsem a écrit :
About [[SetP]]:
* It seems to me that we've traded a duplicated [[GetProperty]]
call for
a duplicated [[GetOwnProperty]] (Step 1 and 5.a) call on the receiver.
This could be avoided by storing the property descriptor at the
This is all going in a good direction.
I only have a few minor comments:
I don't think that [[GetP]] and [[PutP]] need to be internal methods
In spec'ing this I think I would make them be abstract operations. Internal
methods are extensions points that can be over-ridden on a per object basis.
On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote:
On 7 November 2011 16:54, Tom Van Cutsem tomvc...@gmail.com wrote:
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way
in which these
Hi,
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the
way in which these algorithms climb the prototype chain:
http://wiki.ecmascript.org/doku.php?id=strawman:refactoring_put
This is mainly
Hi Tom,
Thanks for all this work!
Le 07/11/2011 16:54, Tom Van Cutsem a écrit :
Hi,
I wrote up an initial (but fairly complete) draft of a proposed
refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms
to change the way in which these algorithms climb the prototype
chain:
20 matches
Mail list logo
