Proxy
On 12/14/16 8:47 PM, Uther Pendragon wrote:
Perhaps it's a bit late... but I'd like to discuss the proxy object. Notably: why no way to define a hook for when a property is called as a function.
See thread at esdiscuss.org/topic/es6-proxy-function-call-trap.
I think I understand why there isn't one.. I presume because how a property is used (I.e. as a property or called as a function) is a level deeper than the recalling of said property. If at all possible, I think it would be incredibly useful.
It's possible, in general; it was there in the proxy proposals at some point, as the thread linked above says. It leads to weird consequences like "foo.bar()" behaving differently from "foo.bar.call(foo)" when everyone expects them to be the same thing.
I presume most implementations define scope variables much like object properties internally.
That's not clear to me at all. In general, non-object environments don't need to support all the operations objects do (e.g. you can't delete bindings), so the implementation tradeoffs are quite different and using a separate codepath for environments and object properties is likely to be appropriate. Certainly the one implementation for which I know this details (SpiderMonkey) has quite different implementations for scope variables and object properties.
On 12/14/16 8:47 PM, Uther Pendragon wrote: > Perhaps it's a bit late... but I'd like to discuss the proxy object. > Notably: why no way to define a hook for when a property is called as a > function. See thread at <https://esdiscuss.org/topic/es6-proxy-function-call-trap>. > I think I understand *why* there isn't one.. I presume because how a > property is used (I.e. as a property or called as a function) is a level > deeper than the recalling of said property. If at all possible, I think > it would be incredibly useful. It's possible, in general; it was there in the proxy proposals at some point, as the thread linked above says. It leads to weird consequences like "foo.bar()" behaving differently from "foo.bar.call(foo)" when everyone expects them to be the same thing. > I presume most implementations define scope > variables much like object properties internally. That's not clear to me at all. In general, non-object environments don't need to support all the operations objects do (e.g. you can't delete bindings), so the implementation tradeoffs are quite different and using a separate codepath for environments and object properties is likely to be appropriate. Certainly the one implementation for which I know this details (SpiderMonkey) has quite different implementations for scope variables and object properties. -Boris
On 15 December 2016 at 03:26, Boris Zbarsky <bzbarsky at mit.edu> wrote:
I presume most implementations define scope
variables much like object properties internally.
That's not clear to me at all. In general, non-object environments don't need to support all the operations objects do (e.g. you can't delete bindings), so the implementation tradeoffs are quite different and using a separate codepath for environments and object properties is likely to be appropriate. Certainly the one implementation for which I know this details (SpiderMonkey) has quite different implementations for scope variables and object properties.
Indeed, the two couldn't be more different. In general, there isn't even a self-contained data structure representing a scope, let alone a unique one. Some variables might live in registers, some on the stack, some on the heap, some in several of those places at different points in time, some are optimised away entirely. Their names are not generally kept around either.
On 15 December 2016 at 03:26, Boris Zbarsky <bzbarsky at mit.edu> wrote: > I presume most implementations define scope >> variables much like object properties internally. >> > > That's not clear to me at all. In general, non-object environments don't > need to support all the operations objects do (e.g. you can't delete > bindings), so the implementation tradeoffs are quite different and using a > separate codepath for environments and object properties is likely to be > appropriate. Certainly the one implementation for which I know this > details (SpiderMonkey) has quite different implementations for scope > variables and object properties. Indeed, the two couldn't be more different. In general, there isn't even a self-contained data structure representing a scope, let alone a unique one. Some variables might live in registers, some on the stack, some on the heap, some in several of those places at different points in time, some are optimised away entirely. Their names are not generally kept around either. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161215/b15f5cf4/attachment.html>
You can always just return a callable from handler.get
. Function closures
are much more ergonomic than proxies for that in my experience, although I
generally make no distinction regarding this
(which only complicates in
this area).
You can always just return a callable from `handler.get`. Function closures are much more ergonomic than proxies for that in my experience, although I generally make no distinction regarding `this` (which only complicates in this area). On Wed, Dec 14, 2016, 20:47 Uther Pendragon <uther420 at gmail.com> wrote: > Perhaps it's a bit late... but I'd like to discuss the proxy object. > Notably: why no way to define a hook for when a property is called as a > function. > > I think I understand *why* there isn't one.. I presume because how a > property is used (I.e. as a property or called as a function) is a level > deeper than the recalling of said property. If at all possible, I think it > would be incredibly useful. This may be outside the intended purpose of > the proxy object, but a proxy for the purposes of a middleware (I hate that > word too) that is more dynamic would be perfect for adaptors etc... > Perhaps it's not feasible, because the proxy hook is best applied at the > point when the property's definition, which brings me to my next > suggestion.... > > What about the ability to alter / define the configuration of a scope > variable, like those on objects with defineProperty... but with simple > scope variables... I presume most implementations define scope variables > much like object properties internally. > > On Dec 14, 2016 2:56 PM, <es-discuss-request at mozilla.org> wrote: > > Send es-discuss mailing list submissions to > es-discuss at mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > es-discuss-request at mozilla.org > > You can reach the person managing the list at > es-discuss-owner at mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: Ranges (Jeremy Martin) > 2. Re: Ranges (Alexander Jones) > 3. Re: Destructuring object outside of var declaration (Jeff Walden) > > > ---------- Forwarded message ---------- > From: Jeremy Martin <jmar777 at gmail.com> > To: Hikaru Nakashima <oao.hikaru.oao at gmail.com> > Cc: es-discuss <es-discuss at mozilla.org> > Date: Wed, 14 Dec 2016 11:55:02 -0500 > Subject: Re: Ranges > While slightly more verbose, the previously suggested `...` syntax does > have a superficial consistency with the spread operator. Both perform an > expansion of sorts, which has a subtle elegance to it, IMO. > > On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima < > oao.hikaru.oao at gmail.com> wrote: > > I understand. > I hope to find a good form of literals. > > Is there a fact that literals are easier to optimize in the following > cases? > > ``` > for (let i of [1 to 5]) { ...... } > vs > for (let i of Array.range(1, 5)) { ...... } > ``` > > If so, it seems that we can attract vendors' interests. > > 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearnshaw at gmail.com>: > > I think you'd be lucky to even get to that stage. Vendors aren't keen on > any kind of backwards incompatibility in new specs and trying to get this > to stage 4 with such a glaring one would be practically impossible. > > It's not just the incompatibility either. You also introduce an > inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same > as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers. > > When you consider these things, it becomes clear that it's not practical > to change the language this way for such a small benefit. > > On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru.oao at gmail.com> > wrote: > > Oh, I understood it. > It looks like serious problem, but it is may not actually. > If this spec change doesn't break web, we can introduce this idea? > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Jeremy Martin > 661.312.3853 <(661)%20312-3853> > http://devsmash.com > @jmar777 > > > ---------- Forwarded message ---------- > From: Alexander Jones <alex at weej.com> > To: Hikaru Nakashima <oao.hikaru.oao at gmail.com>, Jeremy Martin < > jmar777 at gmail.com> > Cc: es-discuss <es-discuss at mozilla.org> > Date: Wed, 14 Dec 2016 20:28:37 +0000 > Subject: Re: Ranges > IMO this is quite unnecessary syntax sugar. Python has everything you > could need here without special syntax. > > On Wed, 14 Dec 2016 at 16:55, Jeremy Martin <jmar777 at gmail.com> wrote: > > While slightly more verbose, the previously suggested `...` syntax does > have a superficial consistency with the spread operator. Both perform an > expansion of sorts, which has a subtle elegance to it, IMO. > > On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima < > oao.hikaru.oao at gmail.com> wrote: > > I understand. > I hope to find a good form of literals. > > Is there a fact that literals are easier to optimize in the following > cases? > > ``` > for (let i of [1 to 5]) { ...... } > vs > for (let i of Array.range(1, 5)) { ...... } > ``` > > If so, it seems that we can attract vendors' interests. > > 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearnshaw at gmail.com>: > > I think you'd be lucky to even get to that stage. Vendors aren't keen on > any kind of backwards incompatibility in new specs and trying to get this > to stage 4 with such a glaring one would be practically impossible. > > > It's not just the incompatibility either. You also introduce an > inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same > as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers. > > > When you consider these things, it becomes clear that it's not practical > to change the language this way for such a small benefit. > > > > On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru.oao at gmail.com> > wrote: > > Oh, I understood it. > It looks like serious problem, but it is may not actually. > If this spec change doesn't break web, we can introduce this idea? > > > _______________________________________________ > > > es-discuss mailing list > > > es-discuss at mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > _______________________________________________ > > > es-discuss mailing list > > > es-discuss at mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > -- > Jeremy Martin > 661.312.3853 <(661)%20312-3853> > http://devsmash.com > @jmar777 > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss at mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > ---------- Forwarded message ---------- > From: Jeff Walden <jwalden+es at mit.edu> > To: Isiah Meadows <isiahmeadows at gmail.com>, Allen Wirfs-Brock < > allen at wirfs-brock.com> > Cc: Nathan Wall <nathan.wall at live.com>, Brendan Eich <brendan at mozilla.com>, > "es-discuss at mozilla.org" <es-discuss at mozilla.org> > Date: Wed, 14 Dec 2016 12:55:46 -0800 > Subject: Re: Destructuring object outside of var declaration > On 11/13/2016 12:33 PM, Isiah Meadows wrote: > > Okay. Is it a spec bug then? Throwing a ReferenceError is surprising and > odd IMHO. > > I think so -- having different sorts of early errors makes it a little > less clear what sort of error should be thrown when two early errors of > different types are in the same script. Last I knew, the spec was > basically just waiting on someone to experiment with pulling the trigger to > make everything a SyntaxError. I've been meaning to do that for awhile, > but it's not a high priority. > > Jeff > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161221/90afe512/attachment-0001.html>
Agreed, but it lacks intent... I.e., the get handler doesn't know whether the return value is being called.
Imagine a layer that is so robust and flexible that, to use it, you don't have to know or care how the things are used... You just do what makes sense and it works... this concept kinda depends on knowing whether something is being called from, read or assigned when the handler is called.
Agreed, but it lacks intent... I.e., the get handler doesn't know whether the return value is being called. Imagine a layer that is so robust and flexible that, to use it, you don't have to know or care how the things are used... You just do what makes sense and it works... this concept kinda depends on knowing whether something is being called from, read or assigned when the handler is called. On Dec 21, 2016 7:05 AM, "Isiah Meadows" <isiahmeadows at gmail.com> wrote: > You can always just return a callable from `handler.get`. Function > closures are much more ergonomic than proxies for that in my experience, > although I generally make no distinction regarding `this` (which only > complicates in this area). > > On Wed, Dec 14, 2016, 20:47 Uther Pendragon <uther420 at gmail.com> wrote: > >> Perhaps it's a bit late... but I'd like to discuss the proxy object. >> Notably: why no way to define a hook for when a property is called as a >> function. >> >> I think I understand *why* there isn't one.. I presume because how a >> property is used (I.e. as a property or called as a function) is a level >> deeper than the recalling of said property. If at all possible, I think it >> would be incredibly useful. This may be outside the intended purpose of >> the proxy object, but a proxy for the purposes of a middleware (I hate that >> word too) that is more dynamic would be perfect for adaptors etc... >> Perhaps it's not feasible, because the proxy hook is best applied at the >> point when the property's definition, which brings me to my next >> suggestion.... >> >> What about the ability to alter / define the configuration of a scope >> variable, like those on objects with defineProperty... but with simple >> scope variables... I presume most implementations define scope variables >> much like object properties internally. >> >> On Dec 14, 2016 2:56 PM, <es-discuss-request at mozilla.org> wrote: >> >> Send es-discuss mailing list submissions to >> es-discuss at mozilla.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.mozilla.org/listinfo/es-discuss >> or, via email, send a message with subject or body 'help' to >> es-discuss-request at mozilla.org >> >> You can reach the person managing the list at >> es-discuss-owner at mozilla.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of es-discuss digest..." >> >> Today's Topics: >> >> 1. Re: Ranges (Jeremy Martin) >> 2. Re: Ranges (Alexander Jones) >> 3. Re: Destructuring object outside of var declaration (Jeff Walden) >> >> >> ---------- Forwarded message ---------- >> From: Jeremy Martin <jmar777 at gmail.com> >> To: Hikaru Nakashima <oao.hikaru.oao at gmail.com> >> Cc: es-discuss <es-discuss at mozilla.org> >> Date: Wed, 14 Dec 2016 11:55:02 -0500 >> Subject: Re: Ranges >> While slightly more verbose, the previously suggested `...` syntax does >> have a superficial consistency with the spread operator. Both perform an >> expansion of sorts, which has a subtle elegance to it, IMO. >> >> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima < >> oao.hikaru.oao at gmail.com> wrote: >> >> I understand. >> I hope to find a good form of literals. >> >> Is there a fact that literals are easier to optimize in the following >> cases? >> >> ``` >> for (let i of [1 to 5]) { ...... } >> vs >> for (let i of Array.range(1, 5)) { ...... } >> ``` >> >> If so, it seems that we can attract vendors' interests. >> >> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearnshaw at gmail.com>: >> >> I think you'd be lucky to even get to that stage. Vendors aren't keen on >> any kind of backwards incompatibility in new specs and trying to get this >> to stage 4 with such a glaring one would be practically impossible. >> >> It's not just the incompatibility either. You also introduce an >> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same >> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers. >> >> When you consider these things, it becomes clear that it's not practical >> to change the language this way for such a small benefit. >> >> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru.oao at gmail.com> >> wrote: >> >> Oh, I understood it. >> It looks like serious problem, but it is may not actually. >> If this spec change doesn't break web, we can introduce this idea? >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> -- >> Jeremy Martin >> 661.312.3853 <(661)%20312-3853> >> http://devsmash.com >> @jmar777 >> >> >> ---------- Forwarded message ---------- >> From: Alexander Jones <alex at weej.com> >> To: Hikaru Nakashima <oao.hikaru.oao at gmail.com>, Jeremy Martin < >> jmar777 at gmail.com> >> Cc: es-discuss <es-discuss at mozilla.org> >> Date: Wed, 14 Dec 2016 20:28:37 +0000 >> Subject: Re: Ranges >> IMO this is quite unnecessary syntax sugar. Python has everything you >> could need here without special syntax. >> >> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin <jmar777 at gmail.com> wrote: >> >> While slightly more verbose, the previously suggested `...` syntax does >> have a superficial consistency with the spread operator. Both perform an >> expansion of sorts, which has a subtle elegance to it, IMO. >> >> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima < >> oao.hikaru.oao at gmail.com> wrote: >> >> I understand. >> I hope to find a good form of literals. >> >> Is there a fact that literals are easier to optimize in the following >> cases? >> >> ``` >> for (let i of [1 to 5]) { ...... } >> vs >> for (let i of Array.range(1, 5)) { ...... } >> ``` >> >> If so, it seems that we can attract vendors' interests. >> >> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearnshaw at gmail.com>: >> >> I think you'd be lucky to even get to that stage. Vendors aren't keen on >> any kind of backwards incompatibility in new specs and trying to get this >> to stage 4 with such a glaring one would be practically impossible. >> >> >> It's not just the incompatibility either. You also introduce an >> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same >> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers. >> >> >> When you consider these things, it becomes clear that it's not practical >> to change the language this way for such a small benefit. >> >> >> >> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru.oao at gmail.com> >> wrote: >> >> Oh, I understood it. >> It looks like serious problem, but it is may not actually. >> If this spec change doesn't break web, we can introduce this idea? >> >> >> _______________________________________________ >> >> >> es-discuss mailing list >> >> >> es-discuss at mozilla.org >> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> es-discuss mailing list >> >> >> es-discuss at mozilla.org >> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> >> >> -- >> Jeremy Martin >> 661.312.3853 <(661)%20312-3853> >> http://devsmash.com >> @jmar777 >> >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> es-discuss at mozilla.org >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> ---------- Forwarded message ---------- >> From: Jeff Walden <jwalden+es at mit.edu> >> To: Isiah Meadows <isiahmeadows at gmail.com>, Allen Wirfs-Brock < >> allen at wirfs-brock.com> >> Cc: Nathan Wall <nathan.wall at live.com>, Brendan Eich <brendan at mozilla.com>, >> "es-discuss at mozilla.org" <es-discuss at mozilla.org> >> Date: Wed, 14 Dec 2016 12:55:46 -0800 >> Subject: Re: Destructuring object outside of var declaration >> On 11/13/2016 12:33 PM, Isiah Meadows wrote: >> > Okay. Is it a spec bug then? Throwing a ReferenceError is surprising >> and odd IMHO. >> >> I think so -- having different sorts of early errors makes it a little >> less clear what sort of error should be thrown when two early errors of >> different types are in the same script. Last I knew, the spec was >> basically just waiting on someone to experiment with pulling the trigger to >> make everything a SyntaxError. I've been meaning to do that for awhile, >> but it's not a high priority. >> >> Jeff >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161221/92b602fc/attachment-0001.html>
Perhaps it's a bit late... but I'd like to discuss the proxy object. Notably: why no way to define a hook for when a property is called as a function.
I think I understand why there isn't one.. I presume because how a property is used (I.e. as a property or called as a function) is a level deeper than the recalling of said property. If at all possible, I think it would be incredibly useful. This may be outside the intended purpose of the proxy object, but a proxy for the purposes of a middleware (I hate that word too) that is more dynamic would be perfect for adaptors etc... Perhaps it's not feasible, because the proxy hook is best applied at the point when the property's definition, which brings me to my next suggestion....
What about the ability to alter / define the configuration of a scope variable, like those on objects with defineProperty... but with simple scope variables... I presume most implementations define scope variables much like object properties internally.
On Dec 14, 2016 2:56 PM, <es-discuss-request at mozilla.org> wrote:
Send es-discuss mailing list submissions to es-discuss at mozilla.org
To subscribe or unsubscribe via the World Wide Web, visit mail.mozilla.org/listinfo/es-discuss or, via email, send a message with subject or body 'help' to es-discuss-request at mozilla.org
You can reach the person managing the list at es-discuss-owner at mozilla.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of es-discuss digest..."
Today's Topics:
---------- Forwarded message ---------- From: Jeremy Martin <jmar777 at gmail.com>
To: Hikaru Nakashima <oao.hikaru.oao at gmail.com>
Cc: es-discuss <es-discuss at mozilla.org>
Date: Wed, 14 Dec 2016 11:55:02 -0500 Subject: Re: Ranges While slightly more verbose, the previously suggested
...
syntax does have a superficial consistency with the spread operator. Both perform an expansion of sorts, which has a subtle elegance to it, IMO.