Re: Proxy

[Andreas Rossberg]

On 15 December 2016 at 03:26, Boris Zbarsky  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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy

[Boris Zbarsky]

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 .


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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proxy

[Uther Pendragon]

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,  wrote:

Send es-discuss mailing list submissions to
es-discuss@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-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@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 
To: Hikaru Nakashima 
Cc: es-discuss 
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 
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 :
>
>> 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, 
>> 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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@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 
To: Hikaru Nakashima , Jeremy Martin <
jmar...@gmail.com>
Cc: es-discuss 
Date: Wed, 14 Dec 2016 20:28:37 +
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  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@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 :
>
> I think you'd be lucky to 

Re: Destructuring object outside of var declaration

[Jeff Walden]

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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Alexander Jones]

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  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@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 :
>
> 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, 
> 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@mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
>
>
> ___
>
>
> es-discuss mailing list
>
>
> es-discuss@mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
>
>
>
> ___
>
> es-discuss mailing list
>
> es-discuss@mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Jeremy Martin]

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 
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 :
>
>> 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, 
>> 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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Hikaru Nakashima]

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 :

> 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, 
> 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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Andy Earnshaw]

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, 
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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss