Re: Global lexical tier

[Andreas Rossberg]

On 3 September 2015 at 01:58, Brendan Eich  wrote:

> I was there, I just re-read and re-remembered. I do not agree with Allen
> that some tiny needle was uniquely threaded. Rather, an aesthetic
> preference for the new ES6 binding forms to have a lexical contour of their
> own when used at top level prevailed. This leads to problems, not all of
> which were known at the time -- but some problems were noted.
>
> The REPL problem, where let z=z; makes a poison pill, could be coped with
> by ad-hoc REPL deviations from the spec -- at some cost. Let's set it aside.
>
> The one-time change to a reference, from global object to lexical
> shadowing binding, is a serious flaw. Yes, it could happen due to explicit
> scope nesting, but the global scope is apparently uniform. There's no
> explicit delimiter.
>

I still maintain that a tower-of-nested-scopes model would have been
cleaner AND would have avoided both the shadowing issue and the REPL
restriction. A mutable scope that gets extended under your feet is
terrible, lexical or not.

I also maintain that putting lexical bindings onto the global object is not
an option. It is incompatible with having a TDZ, unless one wants to
introduce TDZs for properties into the object model, which I doubt anybody
wants. Or unless one makes toplevel binding semantics completely different
(and insane), which I also hope nobody wants (though I'm not so sure).


The implementors seem to be rebelling but I'm not trying to stir up
> trouble. It would help if V8 did support let, etc. in sloppy mode. Then we
> might see open rebellion among two or more implementors.
>

AFAICS this issue is completely orthogonal to sloppy-vs-script, and there
are no new effects specific to sloppy mode. V8 already fully implements the
necessary semantics. It wasn't pretty, but there are uglier things in ES6.

The main thing holding back sloppy let in V8 right now is the parsing
nonsense and extra look-ahead required, which turns out to be a major pain
for us (and FWIW, slows down the V8 parser by a couple of percent with
little hope for recovery :( ).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Brendan Eich]

saam barati wrote:

Thanks. Reading now.

I'm clearly bad at email :/


Naw, this stuff is always harder to find than it should be.

I was there, I just re-read and re-remembered. I do not agree with Allen 
that some tiny needle was uniquely threaded. Rather, an aesthetic 
preference for the new ES6 binding forms to have a lexical contour of 
their own when used at top level prevailed. This leads to problems, not 
all of which were known at the time -- but some problems were noted.


The REPL problem, where let z=z; makes a poison pill, could be coped 
with by ad-hoc REPL deviations from the spec -- at some cost. Let's set 
it aside.


The one-time change to a reference, from global object to lexical 
shadowing binding, is a serious flaw. Yes, it could happen due to 
explicit scope nesting, but the global scope is apparently uniform. 
There's no explicit delimiter.


The implementors seem to be rebelling but I'm not trying to stir up 
trouble. It would help if V8 did support let, etc. in sloppy mode. Then 
we might see open rebellion among two or more implementors.


When it comes to aesthetics vs. implementability and usability, we have 
to throw aesthetics under the bus. This is JavaScript, after all! :-P 
Ok, seriously, we did not actually make anything prettier. The top level 
is hopeless. All we did was leave a couple of hazards for implementors 
and users in ES6.


Making the new binding forms create global properties (or throw trying), 
as I implemented long ago for let in ES4 in SpiderMonkey, is ugly, but 
it does not introduce any net-new hazards.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Brendan Eich]

Andreas Rossberg wrote:
On 3 September 2015 at 01:58, Brendan Eich > wrote:


I was there, I just re-read and re-remembered. I do not agree with
Allen that some tiny needle was uniquely threaded. Rather, an
aesthetic preference for the new ES6 binding forms to have a
lexical contour of their own when used at top level prevailed.
This leads to problems, not all of which were known at the time --
but some problems were noted.

The REPL problem, where let z=z; makes a poison pill, could be
coped with by ad-hoc REPL deviations from the spec -- at some
cost. Let's set it aside.

The one-time change to a reference, from global object to lexical
shadowing binding, is a serious flaw. Yes, it could happen due to
explicit scope nesting, but the global scope is apparently
uniform. There's no explicit delimiter.


I still maintain that a tower-of-nested-scopes model would have been 
cleaner AND would have avoided both the shadowing issue and the REPL 
restriction. A mutable scope that gets extended under your feet is 
terrible, lexical or not.


I don't remember you overcoming the counterarguments about async scripts 
and event handlers in async-generated/written markup twisting the nested 
scopes unexpectedly.


I also maintain that putting lexical bindings onto the global object 
is not an option. It is incompatible with having a TDZ, unless one 
wants to introduce TDZs for properties into the object model,


Nope!

which I doubt anybody wants. Or unless one makes toplevel binding 
semantics completely different (and insane), which I also hope nobody 
wants (though I'm not so sure).


Something has to give. This seems least bad.


The implementors seem to be rebelling but I'm not trying to stir
up trouble. It would help if V8 did support let, etc. in sloppy
mode. Then we might see open rebellion among two or more implementors.


AFAICS this issue is completely orthogonal to sloppy-vs-script, and 
there are no new effects specific to sloppy mode. V8 already fully 
implements the necessary semantics. It wasn't pretty, but there are 
uglier things in ES6.


There's still user not implementor feedback to be gained by V8 
supporting top-level let/const/class in sloppy mode per spec, but fair 
enough.


The main thing holding back sloppy let in V8 right now is the parsing 
nonsense and extra look-ahead required, which turns out to be a major 
pain for us (and FWIW, slows down the V8 parser by a couple of percent 
with little hope for recovery :( ).


I thought we resolved this (non-simple parameter list in function makes 
"use strict"; directive prologue an early error). What's left?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()

[Allen Wirfs-Brock]

On Sep 2, 2015, at 4:10 PM, John-David Dalton wrote:

> Hiya,
> 
> > [Enumerate]] must obtain the own property keys of the target object as if 
> > by calling its [[OwnPropertyKeys]] internal method
> 
> Whoa that's tricky language. I assumed reading it that [[Enumerable]] was to 
> follow the order of [[OwnPropertyKeys]] (as part of "as if by") and walking 
> the prototype chain.

It says "obtain", not "obtain and order".  In other words,  the initial set of 
own properties of the target object must include the same set of keys as 
provided by [[OwnPropertyKeys]] but the order in which they are processed need 
not be the same.  Why?  Because TCD39 was not yet willing to mandate a for-in 
enumeration order.

> 
> It's odd to me that:
> 
>   Reflect.ownKeys() has defined order but
>   Reflect.enumerate() doesn't

Note that [[OwnPropertyKeys]] returns any array whose property ordering is 
fixed when it is returned.
[[Enumerate]] returns an iterator, and the property state of the object that is 
 being iterated over can change between calls to `next1.  That's the big 
difference.

> 
> I'm using Reflect.enumerate() to create a `keysIn` implementation (like 
> `keys` but for own & inherited key names).
> 
> :+1: for more defined behavior in ES7.

me too

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()

[Scott Sauyet]

John-David Dalton  wrote:

> It's odd to me that:
>
>   Reflect.ownKeys() has defined order but
>   Reflect.enumerate() doesn't
>
> I'm using Reflect.enumerate() to create a `keysIn` implementation (like 
> `keys` but for own & inherited key
> names).
>
> :+1: for more defined behavior in ES7.

+1

This same concern was tripping me up this week.

  -- Scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Allen Wirfs-Brock]

On Sep 2, 2015, at 4:58 PM, Brendan Eich wrote:

> saam barati wrote:
>> Thanks. Reading now.
>> 
>> I'm clearly bad at email :/
> 
> Naw, this stuff is always harder to find than it should be.
> 
> I was there, I just re-read and re-remembered. I do not agree with Allen that 
> some tiny needle was uniquely threaded. Rather, an aesthetic preference for 
> the new ES6 binding forms to have a lexical contour of their own when used at 
> top level prevailed. This leads to problems, not all of which were known at 
> the time -- but some problems were noted.

I didn't mean to imply that it was the only threading of the requirement 
needles, but it was the one we could reach consensus on. It isn't even my 
favorite ( I would of preferred something similar to Saam's suggestion) but 
consensus on something was necessary in order to have publish a standard.
> 
> The REPL problem, where let z=z; makes a poison pill, could be coped with by 
> ad-hoc REPL deviations from the spec -- at some cost. Let's set it aside.
> 
> The one-time change to a reference, from global object to lexical shadowing 
> binding, is a serious flaw. Yes, it could happen due to explicit scope 
> nesting, but the global scope is apparently uniform. There's no explicit 
> delimiter.
> 
> The implementors seem to be rebelling but I'm not trying to stir up trouble. 
> It would help if V8 did support let, etc. in sloppy mode. Then we might see 
> open rebellion among two or more implementors.
> 
> When it comes to aesthetics vs. implementability and usability, we have to 
> throw aesthetics under the bus. This is JavaScript, after all! :-P Ok, 
> seriously, we did not actually make anything prettier. The top level is 
> hopeless. All we did was leave a couple of hazards for implementors and users 
> in ES6.
> 
> Making the new binding forms create global properties (or throw trying), as I 
> implemented long ago for let in ES4 in SpiderMonkey, is ugly, but it does not 
> introduce any net-new hazards.

But it introduces many inconsistencies between the semantics of let/const/class 
at the global level and their handling within nested scopes. Also, it 
perpetuates the the pollution of the windows object with program state, the 
avoidance of which was one of the requirements that was being promoted.

The way I see it, when none of the alternatives are good ones, it is TC39's job 
to choose (as long as the choice is implementable). In such cases 
implementations should just follow the spec, unless there is a truly new 
alternative that T39 didn't consider or other new information. It really isn't 
very usefully  to revisit a difficult decision without any new information to 
add to the discussion. 

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Property ordering of [[Enumerate]] / getOwnPropertyNames()

[John-David Dalton]

Hiya,

> [Enumerate]] must obtain the own property keys of the target object as if
by calling its [[OwnPropertyKeys]] internal method

Whoa that's tricky language. I assumed reading it that [[Enumerable]] was
to follow the order of [[OwnPropertyKeys]] (as part of "as if by") and
walking the prototype chain.

It's odd to me that:

  Reflect.ownKeys() has defined order but
  Reflect.enumerate() doesn't

I'm using Reflect.enumerate() to create a `keysIn` implementation (like
`keys` but for own & inherited key names).

:+1: for more defined behavior in ES7.


- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Finding elements that are hidden due to overflow: hidden

[Tab Atkins Jr.]

On Tue, Aug 25, 2015 at 6:39 PM, Behrang Saeedzadeh  wrote:
> Looks like at the moment DOM does not expose any properties that signify
> whether an element has become hidden due to an overflow: hidden on their
> parent element.
>
> Any chance of adding this feature to DOM?

That's a result of CSS layout/rendering; it doesn't seem
super-appropriate to add to the DOM.  It's also a bit troublesome; an
element can be partially hidden, so when does this flag flip to true?
It's also very specific; there are a ton of ways that an element can
get hidden besides being clipped by an overflow:hidden ancestor.
What's the actual use-case you're trying to address here?

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss