Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based on that API.
An interesting question I still haven't
On 25/11/2012, at 00:52, Brendan Eich wrote:
No. You're rehashing a hypothetical worry at this point.
No worries, but it's not a hypothesis that code outside a recursive FD can
break it at its will.
Evidence first, to get any farther.
The only evidence is that sometimes yes sometimes no,
Le 25/11/2012 12:44, Tom Van Cutsem a écrit :
(...)
I agree that the big benefit of notification proxies is that they get
rid of all the complex validation logic.
However, some reservations:
(...)
- I think we do lose some expressiveness in the case of pure virtual
object abstractions that
On Mon, Nov 26, 2012 at 3:36 AM, David Bruant bruan...@gmail.com wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type
Brandon Benvie wrote:
By design, private symbols can only be used if you have direct access
to them in some way.
Right.
Public symbols should show up in getOwnPropertyNames (if I have
followed recent discussion correctly).
I don't recall this, and it's an incompatible change from ES5. Can
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 25, 2012, at 12:41 PM, Tom Van Cutsem wrote:
However, with [[HasProperty]] removed, I assume the in-operator no
longer triggers the has trap when it encounters a proxy, instead doing
the proto-chain-walk itself and calling hasOwn on
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put handlers.
I think that dealing with it in a Get/SetInheritance handler would be a
much more efficient way to hand this extremely rare operation. Rather than
filtering for it on
On Nov 26, 2012, at 9:44 AM, Tom Van Cutsem wrote:
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 25, 2012, at 12:41 PM, Tom Van Cutsem wrote:
However, with [[HasProperty]] removed, I assume the in-operator no longer
triggers the has trap when it encounters a proxy, instead
Ah I guess I misread what was said back in the July meeting and then
misinterpreted the recent discussion in that framing. The recent discussion
I'm referring to is at and around
https://mail.mozilla.org/pipermail/es-discuss/2012-November/026536.html
On Mon, Nov 26, 2012 at 12:41 PM, Brendan
Or I guess to clarify, I don't understand what the distinction is between a
private symbol and a unique symbol if unique symbols don't show up
anywhere. So I jumped to the assumption that they did show up in gOPN based
on what I read.
On Mon, Nov 26, 2012 at 1:32 PM, Brandon Benvie
On Nov 26, 2012, at 10:00 AM, Tom Van Cutsem wrote:
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put handlers. I
think that dealing with it in a Get/SetInheritance handler would be a much
more efficient way to hand this
2012/11/26 David Bruant bruan...@gmail.com
Le 26/11/2012 19:00, Tom Van Cutsem a écrit :
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put handlers.
I think that dealing with it in a Get/SetInheritance handler would be a
2012/11/26 Brandon Benvie bran...@brandonbenvie.com
Or I guess to clarify, I don't understand what the distinction is between
a private symbol and a unique symbol if unique symbols don't show up
anywhere. So I jumped to the assumption that they did show up in gOPN based
on what I read.
For
On Nov 26, 2012, at 10:13 AM, David Bruant wrote:
Le 26/11/2012 19:00, Tom Van Cutsem a écrit :
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put handlers. I
think that dealing with it in a Get/SetInheritance handler would
Le 26/11/2012 19:37, Allen Wirfs-Brock a écrit :
On Nov 26, 2012, at 10:00 AM, Tom Van Cutsem wrote:
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put
handlers. I think that dealing with
One way or another we need a way to reflectively identify all the non-private
own property keys of an object including non-private symbols keys.
If we think the compat risk of adding symbols to the result of
Object.getOwnProperyNames is too great (and we've recently discussed why this
might
2012/11/26 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 26, 2012, at 9:44 AM, Tom Van Cutsem wrote:
W.r.t. freeze and friends, I thought you were considering a more generic
[[GetIntegrity]]/[[SetIntegrity]] operation.
Yes, are you on board with that?
Yes, I haven't yet considered all
On Nov 26, 2012, at 12:36 AM, David Bruant wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based
Le 26/11/2012 19:58, Allen Wirfs-Brock a écrit :
On Nov 26, 2012, at 12:36 AM, David Bruant wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
I have a couple virtual object use cases in mind where I don't think I
would want to make all properties concrete on the target.
Thanks for spelling out these examples. While they still don't feel like
actual important use cases to support,
There's a few goals I have in mind when thinking about proxies:
* Ability to forward to target at minimal cost.
* Minimal cost for invariant enforcement, preferably automatic since the
result is predetermined
* Near zero cost for invariant enforcement in the majority of cases where
it's not needed
I started to respond to Allan's message, but I'll combine them to here.
Note the additional proposal in the middle of the message.
On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
I have a couple virtual object use
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
We could define a symbolic value (like StopIteration for
iterators) that would mean forward to target. By essence of what
forwarding to the target means, there would be
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies
thread and similar ones be rather well-known unique symbols (like
@iterator), now that we have them, instead of well-known globals?
On the more general line, I got pretty fond of (unique) symbols, they
seem like very
On Nov 26, 2012, at 10:56 AM, Tom Van Cutsem wrote:
2012/11/26 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 26, 2012, at 9:44 AM, Tom Van Cutsem wrote:
W.r.t. freeze and friends, I thought you were considering a more generic
[[GetIntegrity]]/[[SetIntegrity]] operation.
Yes, are you
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies
thread and similar ones be rather well-known unique symbols (like
@iterator), now that we have them, instead of well-known globals? \
Why?
Let's separate the naming and unique identity concerns.
On Nov 26, 2012, at 1:11 PM, Brendan Eich wrote:
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies thread
and similar ones be rather well-known unique symbols (like @iterator), now
that we have them, instead of well-known globals? \
Why?
Le 26/11/2012 22:11, Brendan Eich a écrit :
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies
thread and similar ones be rather well-known unique symbols (like
@iterator), now that we have them, instead of well-known globals? \
Why?
Let's separate
On Nov 26, 2012, at 5:27 PM, Brendan Eich wrote:
David Bruant wrote:
Le 26/11/2012 22:11, Brendan Eich a écrit :
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies
thread and similar ones be rather well-known unique symbols (like
@iterator), now
29 matches
Mail list logo
