Proxy

Uther Pendragon uther420 at gmail.com
Wed Dec 21 13:22:30 UTC 2016


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>


More information about the es-discuss mailing list