About functions, what is the benefit of having a call trap?
A function proxy (typeof === function) can only be created is the
target contains a [[Call]] internal method (by definition of typeof and
the fact that it's forwarded from the proxy to the target). So, why
having a trap instead of
2011/10/18 David Herman dher...@mozilla.com
Hi Tom, this looks very promising. Some comments below; quoting the wiki
page inline.
* target is the object which the direct proxy wraps
Just checking: presumably this proposal doesn't allow for target to be a
primitive, right? (Other than the
Even simpler:
var arrayProxy = Proxy.for([], {
get: function(name, target) {
if (!(name in target)) {
return function(...args) { /* no such method behavior here */ }
}
}
});
That assumes you are the creator of the array. If it already exists,
Proxy.startTrapping would be able
2011/10/18 David Bruant bruan...@gmail.com
About functions, what is the benefit of having a call trap?
A function proxy (typeof === function) can only be created is the target
contains a [[Call]] internal method (by definition of typeof and the fact
that it's forwarded from the proxy to the
Hi,
The initial proxy proposal was about to provide proxy as an additional
argument to all traps.
The current proxy has target instead, but still proxy for get and
set traps.
Regardless of the proposal, I have recently come up with a use case [1]
where I expressed the need of passing the
On 13/10/2011, at 20:05, Allen Wirfs-Brock wrote:
People coming to JS from C/C++/Java are generally happy with the JS syntax
(but don't like other things about it). People coming from Ruby or Python
generally aren't happy with JS syntax.
There's many more JS/C/C++/Java programmers than
On 18 October 2011 17:08, David Bruant bruan...@gmail.com wrote:
Ok for typeof. But there are other places where [[Call]] is used and the
proxy is expected to (indirectly) expose it. For instance bind:
-
var fpb = Function.prototype.bind;
var bind = fpb.bind(fpb);
var p =
2011/10/18 Andreas Rossberg rossb...@google.com
Finally, I'm not sure I fully understand the performance implications
of direct proxies vs the current proposal. From looking at your
prototype implementation, it seems that we need quite a number of
additional checks and calls, even for
On 18 October 2011 17:48, Tom Van Cutsem tomvc...@gmail.com wrote:
2011/10/18 Andreas Rossberg rossb...@google.com
First, Proxy.startTrapping (a.k.a. Proxy.attach). As far as I can see,
this implies a significantly more general 'become' operation than the
current semantics. I don't see how we
On Tue, Oct 18, 2011 at 9:51 AM, Andreas Rossberg rossb...@google.comwrote:
Good point. Yet another reason why I prefer the alternate
Proxy.temporaryFor
API I sketched in reply to Dave Herman. That API does not necessarily
suffer
from this issue.
Yes, I think that interface, while less
Le 18/10/2011 17:17, Sean Eagan a écrit :
On Tue, Oct 18, 2011 at 6:45 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
The initial proxy proposal was about to provide proxy as an
additional argument to all traps.
The current proxy has target
On Mon, Oct 17, 2011 at 13:42, Brendan Eich bren...@mozilla.com wrote:
Maybe we can hold the line at private-named iterate and defaultValue
unstratified traps. I'm looking for two things:
1. Feedback from implementors on not trapping non-proxy objects based on
private names being mapped.
Le 18/10/2011 17:28, Andreas Rossberg a écrit :
On 18 October 2011 13:45, David Bruant bruan...@gmail.com wrote:
Another alternative would be to do natively what we've been doing in code
which is that when a call is trapped, instead of using the handler, an new
object is created. This object
If I define a setter for Array.prototype[0], does [].push invoke that setter?
Test code:
!doctype htmlhtmlbody
script
Object.defineProperty(
Array.prototype, 0,
{ get : function() { alert('get 0'); return this.zero; },
set : function(v) { alert('set 0 ' + v); this.zero = v; },
On Oct 18, 2011, at 12:31 PM, felix wrote:
If I define a setter for Array.prototype[0], does [].push invoke that setter?
It's supposed to.
Test code:
!doctype htmlhtmlbody
script
Object.defineProperty(
Array.prototype, 0,
{ get : function() { alert('get 0'); return this.zero;
Hi David,
What you seem to want is the ability to define new kinds of properties in
addition to data and accessor properties. That is beyond the goal of
proxies.
However, I really don't see why you would want to define your event
properties as a third type of property. What would be the problem
2011/10/18 David Bruant bruan...@gmail.com
True. The idea of a |this| being a forwarding proxy with the handler as
its target can still hold since it would just be one additional identity
and some magic for the particular property names proxy, target and
receiver.
Binding this inside a
Le 18/10/2011 21:47, Tom Van Cutsem a écrit :
Hi David,
What you seem to want is the ability to define new kinds of properties
in addition to data and accessor properties. That is beyond the goal
of proxies.
If proxies allow to pass property descriptor attributes other than
On Oct 18, 2011, at 12:49 PM, Tom Van Cutsem wrote:
2011/10/18 David Bruant bruan...@gmail.com
True. The idea of a |this| being a forwarding proxy with the handler as
its target can still hold since it would just be one additional identity
and some magic for the particular property names
I have been thinking that proxies could be a nice way of having private data
members instead of the private name proposal. The target would be the full
implementation, including all private members done as normal properties.
Then the implementation object would get wrapped with a proxy, exposing
On Oct 18, 2011, at 1:25 PM, Russell Leggett wrote:
I have been thinking that proxies could be a nice way of having private data
members instead of the private name proposal. The target would be the full
implementation, including all private members done as normal properties.
Then the
On Tue, Oct 18, 2011 at 4:28 PM, Brendan Eich bren...@mozilla.com wrote:
On Oct 18, 2011, at 1:25 PM, Russell Leggett wrote:
I have been thinking that proxies could be a nice way of having private
data members instead of the private name proposal. The target would be the
full
On Oct 18, 2011, at 2:06 PM, Russell Leggett wrote:
I don't necessarily think data hiding should *have* to reach for them, but
the functionality is already there with them.
Closures are the current best way to hide information in JS. With ES5's
standardized accessors, you can have public
There are other alternatives, such as supporting both alternatives with two
different entry points (con: API proliferation), taking an optional boolean
flag indicating to return the pair (con: too dynamic a type), taking an
optional outparam object (con: what is this? C?). OK, so most of those
We could even allow for direct proxies to acquire non-standard internal
properties from their target object. This could be a useful principle when
wrapping host objects.
This seems important in order to make host methods work, e.g., the ones that
access the [[Value]] property. I guess
25 matches
Mail list logo
