Re: Global lexical tier

Andreas Rossberg wrote: What I mean is that in a model with mutable scope (or worse, the global object) _declarations_ themselves become global effects. Later conflicts can affect all code that has been loaded _before_, e.g. by smashing over an existing binding. I get it, but this is just "th

Re: Global lexical tier

On 3 September 2015 at 20:57, Brendan Eich wrote: > Andreas Rossberg wrote: > >> On 3 September 2015 at 03:50, Brendan Eich > bren...@mozilla.org>> wrote: >> >> I don't remember you overcoming the counterarguments about async >> scripts and event handlers in async-generated/written markup

Re: Global lexical tier

On Sep 3, 2015, at 2:30 PM, Brendan Eich wrote: >> \ > > Global script is global, though. I don't see how you can have > > > class Widget {...} > > ... > > let w = new Widget(); > ... > > > fail for want of an extra step to export Widget from the first script and > import it into the s

Re: Global lexical tier

Allen Wirfs-Brock wrote: 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 w

Re: Global lexical tier

Andreas Rossberg wrote: On 3 September 2015 at 03:50, Brendan Eich > wrote: I don't remember you overcoming the counterarguments about async scripts and event handlers in async-generated/written markup twisting the nested scopes unexpectedly. The only ca

Re: Global lexical tier

As you probably read (agreed, notes are strung out and not well-indexed), we considered that too. It fell to the objection that users certainly want const and class declarations from one script to be usable in subsequent scripts. For let, we didn't want to break symmetry with const and class at

Re: Global lexical tier

Sorry for the confusion, I was talking about my stated preference that all lexical variables should be local to the program they're defined in. On Thu, Sep 3, 2015 at 11:30 AM, Brendan Eich wrote: > saam barati wrote: > >> I think we've also hurt ourselves here with regards to considering >> alt

Re: Global lexical tier

saam barati wrote: I think we've also hurt ourselves here with regards to considering alternate implementations by having some form of "const" being visible across multiple JS programs for a while now. This property of top-level const being visible across mutliple programs (script elements) h

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

On Thu, Sep 3, 2015 at 3:26 AM, Behrang Saeedzadeh wrote: > Hi Tab, > > My use case can already be implemented using JavaScript and some existing > properties on elements such as clientLeft and its cousins. > > Here's a simplified version of my use case: > http://codepen.io/behrangsa/pen/PPozWj T

Re: Global lexical tier

After reading through past threads and meeting notes, I've changed my opinion. I think the current spec is OK and meets the real needs of programs today. I've ran into real programs that break without the global lexical tier while implementing this inside JavaScriptCore. While I don't think global

Re: Global lexical tier

On 3 September 2015 at 03:50, Brendan Eich wrote: > Andreas Rossberg wrote: > >> On 3 September 2015 at 01:58, Brendan Eich > bren...@mozilla.org>> 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,

Re: Accounting for leap seconds for "this time value"

Wouldn't the leap seconds be only formatting for display where as time stored in epochs is universal? If I'm on Mars the epochs value is the same whereas local time (on Mars) may have a totally different set of adjustments to keep the human readable time true to that planets rotation etc. 📱 Mi

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

Hi Tab, My use case can already be implemented using JavaScript and some existing properties on elements such as clientLeft and its cousins. Here's a simplified version of my use case: http://codepen.io/behrangsa/pen/PPozWj But I thought it would be nicer if an element had a method that could be

Re: Accounting for leap seconds for "this time value"

That means that `Date.now()/1000` is the [Unix time] (https://en.wikipedia.org/wiki/Unix_time ), which can't represent leap seconds. In particular, each minute is assumed to have exactly 60 seconds, and thus it is impossible to represent `1981-06-30 23:

Accounting for leap seconds for "this time value"

The current specification has this to say about the time value in dates: "Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. > In time values leap seconds are ignored. It is assumed that there are > exactly 86,400,000 milliseconds per day." What I would like to seek clari