Re: How to solve this basic ES6-module circular dependency problem?

Without a way to load "later" (aka "soft") dependencies, ES6 module will continue to be more or less broken for circular dependencies. On Tue, Aug 9, 2016 at 4:11 PM, Tab Atkins Jr. wrote: > On Tue, Aug 9, 2016 at 4:00 PM, /#!/JoePea wrote: > > True, and so that's why I'm wondering if the modul

Proposal: Splitting the "Standard Library" from the EcmaScript spec

A fair amount of text in the EcmaScript spec is spent on defining the EcmaScript standard classes and methods. This has the side-effect of doing two things: - encouraging standard classes/methods to have special behavior - discouraging creating appropriate "building blocks" How differently w

Re: Code smell? Iterator prototype has iterator method that returns "this"

Yes, but at the cost of being able to reason / declare what kind of object is actually required. But, I'm sure there is nothing that can be changed here. On Mon, Jul 25, 2016 at 4:31 PM, Tab Atkins Jr. wrote: > On Mon, Jul 25, 2016 at 4:28 PM, John Lenz wrote: > > I understand

Re: Code smell? Iterator prototype has iterator method that returns "this"

I understand the way it is used, but I don't understand why. "for-of" could have been spec'd to take either an Iterable (an object with an [Symbol.iterator] method) or an Iterator. Or just an Iterable. On Mon, Jul 25, 2016 at 8:38 AM, Boris Zbarsky wrote: > On 7/25

Code smell? Iterator prototype has iterator method that returns "this"

This seems ripe for misuse: you don't want two "owners" for the same iterator calling "next" and normally, without the Iterator interface implementation, you would expect "iterator()" to always return an instance of the iterator that the caller "owned". Can anyone provide any historical context o

Re: operator overloading proposal

y a few years down >> the road, it may later become practical to break forward compatibility in >> that way due to lack of usage. It's not a common use case, though, to send >> an object of unknown type to an asm.js function, and replacing native >> methods fails valid

Re: Re: Existential Operator / Null Propagation Operator

It is a parser problem: obj.prop?.2:.1 You need arbitrary look ahead to disambiguate ?. from ?: solve the problem. On Tue, May 10, 2016 at 10:32 AM, wrote: > Why isn't it possible to use the obj.property?.sub syntax in combination > with lookahead as suggested by Brendan Eich 4 years ago? > >

Re: operator overloading proposal

I have some concerns. With the short circuiting operators: Commutative operators, +, *, &&, ||, &, |, ^, automatically flip the order of operands when their types are different. && and || can not "flip" and routing them through a method is not compatible with short-circuiting. Generally, t

Re: extending an ES6 class using ES5 syntax?

On Sun, May 15, 2016 at 6:23 PM, Rob Brackett wrote: > > I'm trying to provide a path where common code can migrate to ES6 > classes before all the consumers have. So I was really looking for > something that didn't require the subclasses to be touched at all (I wasn't > clear about this). > >

Re: extending an ES6 class using ES5 syntax?

I'm trying to provide a path where common code can migrate to ES6 classes before all the consumers have. So I was really looking for something that didn't require the subclasses to be touched at all (I wasn't clear about this). I have a fair amount of control over how the inheritance is setup an

extending an ES6 class using ES5 syntax?

Specifically, I'm looking for a way to call an super class ES6 constructor without violating the "new" rule (TypeError: Class constructor A cannot be invoked without 'new'): class A { } function B() { A.call(this); // this breaks } B.prototype = Object.create(A.prototype); Without something

Re: Pseudo headless arrows

_=>{} is a function that takes one param and is not equivalent to ()=>{}. Some test frameworks inspect the function and care about the difference. On Apr 21, 2016 3:34 PM, "Fabrício Matté" wrote: The `==>` token would look like a new operator, which developers would have to look up in order to kn

Re: meeting notes for march 2016?

great, I was expecting an announcement here. On Wed, Apr 20, 2016 at 1:45 PM, Michael Ficarra wrote: > The notes have already been posted at > https://github.com/tc39/tc39-notes/tree/4d5fb147e6b714f682aaf5da803ca14ec5fb3b82/es7/2016-03 > . > > On Wed, Apr 20, 2016 at 7:45 AM, J

Re: meeting notes for march 2016?

Any update on this? On Wed, Apr 6, 2016 at 4:25 PM, Rick Waldron wrote: > Where are they? I haven't seen anyone post them for approval. > > On Tue, Apr 5, 2016 at 8:39 PM Jordan Harband wrote: > >> The notes were taken, but have not yet been approved and posted on >> https://github.com/rwaldron

Re: Destructuring default values with empty strings

I think an appropriate map call will let you do anything you want here. On Mar 27, 2016 4:51 AM, "Cyril Auburtin" wrote: > when doing let [tag = 'cat', ...cls] = '.foo.bar'.split('.') > > I'd find it more logical to use the default value for all falsy values > like an empty string '' for the tag

Re: Async iteration

On Mon, Mar 14, 2016 at 11:19 AM, Kevin Smith wrote: > Is there a summary of the motivation for "for-await" and "async iteration" >> in general? >> > > There's a short section at: > https://github.com/tc39/proposal-async-iteration#overview-and-motivation > Thanks > > >> Has there any discussio

Async iteration

Two things: Is there a summary of the motivation for "for-await" and "async iteration" in general? Has there any discussion in not supporting "var" in "for-await" initializers? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/

Re: Will it be possible to retrieve a loaded module's exports synchronously?

On Wed, Feb 24, 2016 at 7:35 PM, Caridy Patiño wrote: > inline (but again, we should move this conversation to the loader repo > where you will get more people looking at your questions)... > > https://github.com/whatwg/loader/issues/130 > On Feb 24, 2016, at 7:57 PM, J

Re: Will it be possible to retrieve a loaded module's exports synchronously?

but there is no guarantee that you > get it, it depends on the current stage of the module in the pipeline. > I having a hard time here to trying to understand what I can say differently to explain what I desire: I need to know if a module is loaded and ready, if it is I want the module expo

Re: Will it be possible to retrieve a loaded module's exports synchronously?

do what you > please, but there is no guarantee that the module status that you’re > looking for is accessible (they can be removed from the registry and still > function). > > You should probably post this question on whatwg/loader repo. > > /caridy > > > On Feb 24, 2016, at 5

Re: Will it be possible to retrieve a loaded module's exports synchronously?

cess to the >> registry of every loader instance, you can walk each registry, and do what >> you please, but there is no guarantee that the module status that you’re >> looking for is accessible (they can be removed from the registry and still >> function). >> >

Will it be possible to retrieve a loaded module's exports synchronously?

Background: I'm trying to plan a migration to ES6 modules. For interop with the existing systems in the short-medium term, I would like to be able to retrieve a loaded modules exports synchronously (basically a "get or fail"). It looks like retrieving the exports synchronously is possible using

Re: Error stack strawman

9 February 2016 at 06:29, John Lenz wrote: >> >>> However, at the CPU level, it seems like you would be better pushing an >>> return address for a special function that indicated the start of a >>> sequence of tail calls. That way you trade only some >>> c

Re: Weak Reference proposal

ss inherent in GC/weakref collection. On Fri, Feb 19, 2016 at 5:51 PM, Mark S. Miller wrote: > On Fri, Feb 19, 2016 at 5:36 PM, John Lenz wrote: > >> The finalizer holdings, could itself could hold a reference to the >> weakrefernce correct? >> > > The holdings

Re: Weak Reference proposal

h cycles of > executors pointing at each other's targets such that neither can ever be > collected because the system is keeping them around strongly. > > On Thu, Feb 18, 2016 at 10:42 PM, John Lenz wrote: > >> This seems like a very solid proposal. I like that the finalizers

Re: Weak Reference proposal

This seems like a very solid proposal. I like that the finalizers run on their own turn (it had to be that way in retrospect). I'm unclear about one thing: the reasoning for not running finalizers when weak-references them become unreferenced. Did I misunderstand this? Doesn't this force he "har

Re: Error stack strawman

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add that. A frame is created by the callee, >

Re: Error stack strawman

Mark Knichel has a lot of information regarding stacks and error handling in various browsers here: https://github.com/mknichel/javascript-errors On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo wrote: > The strawman looks very old, so I've created a new one. > > Repo: https://github.com/nbdd0121/es-e

Re: Optional Chaining (aka Existential Operator, Null Propagation)

If we ever hope to include "elvis". obj?:[expr] would be roughly equivalent to: obj != null ? obj : [expr] rather than what you are suggesting here: obj != null ? obj[expr] : undefined; On Sun, Feb 7, 2016 at 4:16 PM, Bergi wrote: > Claude Pache wrote: > >> >> .? >>> (?) >>> [?] >>> >> >>

Re: Optional Chaining (aka Existential Operator, Null Propagation)

On Thu, Feb 4, 2016 at 10:06 AM, Claude Pache wrote: > > Le 4 févr. 2016 à 17:47, John Lenz a écrit : > > > [...] > > > Waldemar's example makes the problem obvious but I think we could do use, > which I think is preferable to the proposed: > > .? > (?)

Re: Optional Chaining (aka Existential Operator, Null Propagation)

On Wed, Feb 3, 2016 at 2:41 PM, Claude Pache wrote: > > > Le 3 févr. 2016 à 20:56, John Lenz a écrit : > > > > Can you reference something as to why the more obvious operators are > problematic? > > > > ?. > > That one (that I've used) must wo

Re: Optional Chaining (aka Existential Operator, Null Propagation)

Can you reference something as to why the more obvious operators are problematic? ?. ?[] ?() ?: On Fri, Jan 29, 2016 at 7:19 AM, Claude Pache wrote: > Hi, > > I have prepared a strawman for the `?.` operator: > > https://github.com/claudepache/es-optional-chaining/ > > If there is interest in t

Re: Specifying the Existential Operator using Abrupt Completion

Did this happen? I would like to see some progress here. On Wed, Jan 13, 2016 at 10:51 AM, Claude Pache wrote: > > Le 13 janv. 2016 à 18:06, C. Scott Ananian a > écrit : > > On Wed, May 21, 2014 at 8:33 AM, Claude Pache > wrote: > >> >> I have thought about the right semantics (and the issue

Re: Reflection to know if executed within a generator/async ?

I don't think being executed in a generator or async function is a good signal that a promise should be returned (something needs to "await" the promise). The async function is really a chain of synchronous code split at various points, during the synchronous parts the code would still need to be

Re: Are there any 64-bit number proposals under consideration?

so what is needed is a "maximally minimal int64 proposal"? On Mon, Nov 16, 2015 at 4:49 PM, Waldemar Horwat wrote: > There have been proposals for 64-bit integers in TC39 for the last 15 > years. All of them so far have gotten bogged down by one of: > > - extending the scope of the proposal to

Re: Are there any 64-bit number proposals under consideration?

Thanks for the pointer, what is that status of that? On Fri, Nov 13, 2015 at 9:45 AM, Joshua Bell wrote: > http://littledan.github.io/int64.html > > On Thu, Nov 12, 2015 at 11:41 PM, John Lenz wrote: > >> I should have been more precise, I meant 64-bit integers, not gr

Re: Are there any 64-bit number proposals under consideration?

I should have been more precise, I meant 64-bit integers, not greater precision floating points (although, I'm sure that would be interesting too). On Thu, Nov 12, 2015 at 10:07 PM, Sam Ruby wrote: > On Fri, Nov 13, 2015 at 1:00 AM, John Lenz wrote: > > By this I mean, a usabl

Are there any 64-bit number proposals under consideration?

By this I mean, a usable type like by mere mortals, not generated C++ code. Maybe something like: var v64 = LongNumber.from('2e58'); v64 = LongNumber.add(v64, 2); It doesn't have to be pretty just reasonably and perform closer to native speed. ___ es-

Re: treated as a module if ...

I thought at one time a naming convention was proposed: x.m.js for es6 modules. But I haven't seen any traction for it. On Jul 6, 2015 12:08 PM, "Allen Wirfs-Brock" wrote: > > On Jul 6, 2015, at 7:32 AM, John Barton wrote: > > > > On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola wrote: > >> To

Re: Parser for ES6?

The Closure Compiler parser is here: https://github.com/google/closure-compiler/tree/master/src/com/google/javascript/jscomp/parsing/parser I know it is still missing new.target, I believe it is otherwise up to date. On Thu, May 7, 2015 at 10:42 AM, Michael Ficarra wrote: > The Shift parser ha

Re: is an iterator allowed to reuse the same "state" object?

Wirfs-Brock wrote: > > On Apr 28, 2015, at 4:21 PM, John Lenz wrote: > > You would hope that the engines might be able to create these objects on > the stack but I don't think anyone does that yet and the result is a flood > of eden objects. > > I would like to know I&#

Re: is an iterator allowed to reuse the same "state" object?

n Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: > > On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: > > By which I mean the object that returns the current value and "done" state? > > > IIRC, it's not supposed to. The built-in iterators will return fresh

is an iterator allowed to reuse the same "state" object?

By which I mean the object that returns the current value and "done" state? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Maximally minimal stack trace standardization

/Caja specifically. But hopefully, I'm missing something. On Mar 11, 2015 9:01 PM, "Brendan Eich" wrote: > John Lenz wrote: > >> >> b) It differs so wildly between platforms that cross-web content >> can't rely on it. >> >> >> I

Re: Maximally minimal stack trace standardization

On Wed, Mar 11, 2015 at 6:53 PM, Mark Miller wrote: > > On Wed, Mar 11, 2015 at 6:31 PM, John Lenz wrote: > >> I'll retract that suggestion having tried to write an argument for it. >> > > Thanks. > > > >> It sad though, removing "stack&qu

Re: Maximally minimal stack trace standardization

g >>>> it a non-interoperable mess while adding a second API. >>>> >>>> >>>> >>>> I also don’t see why .stack cannot map backward through different >>>> source maps. Again, a getter and a function are isomorphic in this reg

Re: Maximally minimal stack trace standardization

one Error.prototype.stack. But what > getStack function is in scope can differ per scope as well as per loader. > > > >> >> >> *From:* Mark S. Miller [mailto:erig...@google.com] >> *Sent:* Wednesday, March 11, 2015 12:12 >> *To:* Domenic Denicola >> *Cc:* John

Re: Maximally minimal stack trace standardization

ogle-caja/source/browse/trunk/src/com/google/caja/ses/debug.js> > makes to parse despite these differences in stack format. As long as we're > standardizing something not compat with web-wide legacy, as we must, we > might as well also fix this security leak in the process. &g

Re: Maximally minimal stack trace standardization

On Mon, Mar 9, 2015 at 5:45 PM, Mark S. Miller wrote: > On Mon, Mar 9, 2015 at 5:02 PM, John Lenz wrote: > >> >> >> On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller >> wrote: >> >>> On Sat, Mar 7, 2015 at 2:55 PM, John Lenz wrote: >>> >

Re: Maximally minimal stack trace standardization

On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller wrote: > On Sat, Mar 7, 2015 at 2:55 PM, John Lenz wrote: > >> I wanted to ping this thread and see how we could get "max-min stack >> traces" to the next step? >> > > Hi John, the best way to take th

Re: Maximally minimal stack trace standardization

t; devtools and other code applications (like Carl Smith's) can create rich > UIs for this data. > > I'm sure the smart people at TC39 can come up with a good (or good enough) > way to represent PTCs. > > > > On Sat, Oct 4, 2014 at 9:31 AM, John Lenz wrote: > >

Re: Cancellation architectural observations

This summaries my concerns and attitude toward this issue very well, thank you. On Mon, Mar 2, 2015 at 3:06 PM, Tab Atkins Jr. wrote: > Thanks for this summary of some concerns! All valid, I think. > > In the GitHub issue > , there are >

Re: Proposal: Additional Meta Properties for ES7

I was recently discussion Promise optimizations (specifically, that in any "then" chain at least one Promise object is created that goes unused), this could be solved by some metadata that indicated whether the result of the function would be consumed: Promise.prototype.then = function(a, b) {

Re: Cancelable promises

On Fri, Feb 27, 2015 at 7:49 PM, John Lenz wrote: > Closure Library's promise implementation supports "cancel": > > > https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502 > > A promise is cancelled only if all the "ch

Re: Cancelable promises

Closure Library's promise implementation supports "cancel": https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502 A promise is cancelled only if all the "child" promises are also cancelled. On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi < andrea.giammar.

Re: `throw` as an expression?

Sure, but there is no pressing need here, "return" as an expression would be more interesting. Not that I'm asking for that. On Oct 9, 2014 4:50 PM, "Brendan Eich" wrote: > John Lenz wrote: > >> or a simple utility method >> > > Current keywor

Re: arrow functions and dart

On Tue, Sep 23, 2014 at 4:19 AM, Caitlin Potter wrote: > We already have two (three? not sure about JSC) engines which implement > arrow functions, plus Traceur. > And Closure Compilers' ES6 -> ES5 support. :-). (shameless plug) > It seems silly to talk about changing the syntax at this poin

Re: `throw` as an expression?

or a simple utility method On Thu, Oct 9, 2014 at 6:35 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > probably not exactly the fat arrow usage you were looking for ... but it > makes it trivial to inline any sort of block > > ```js > asyncFunc() > .then(count => count >= 0 ? count

Re: Maximally minimal stack trace standardization

Is ES6 "shipping" PTCs without implementer feedback? Or how have those that tried dealt with stack traces? On Sep 29, 2014 3:20 PM, "John Lenz" wrote: > What does TC39 expect with regard to PTC and the > standard-because-everyone-has-one "stack" property? Ha

Re: Maximally minimal stack trace standardization

I don't believe we want source map involved as, as you say, that information needs to be retrieved separately. On Sep 30, 2014 5:17 AM, "Fitzgerald, Nick" wrote: > On 9/30/14, 3:44 AM, John Lenz wrote: > > It is a defacto standard. > On Sep 29, 2014 6:36 PM, "

Re: Maximally minimal stack trace standardization

It is a defacto standard. On Sep 29, 2014 6:36 PM, "Brendan Eich" wrote: > Carl Smith wrote: > >> If the source URL hack, or some cleaner wrapper for it, was standardised, >> it'd make all the difference. >> > > Why don't we just make the source URL hack a de-facto standard? That's how > evolutio

Re: Maximally minimal stack trace standardization

What does TC39 expect with regard to PTC and the standard-because-everyone-has-one "stack" property? Has any of the VMs actually tried to implement PTC for JS? On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > >> No particular reason an implementation can't opt

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 12:19 PM, Steve Fink wrote: > On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote: > > On Mon, Sep 29, 2014 at 10:55 AM, John Lenz > wrote: > >> I really have no idea what the behavior should be in the faces of > optimized > >> tail calls (

Re: Maximally minimal stack trace standardization

The issues with "sourceUrl" and syntax errors is fixed in the latest Chrome dev channel and should be making its way to us in the near future. :-) On Mon, Sep 29, 2014 at 11:49 AM, Carl Smith wrote: > Just wanted to add that CoffeeShop [ > https://github.com/carlsmith/coffeeshop] already uses st

Re: Maximally minimal stack trace standardization

On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo wrote: > I would also like to see this standardized. Comments inline. > > > On Sep 27, 2014, at 10:15 PM, John Lenz wrote: > > > > I would like to get see stack traces standardized for ES7, to that end, > I would like

Re: Maximally minimal stack trace standardization

Of course a standard string format can be machine readable (we maintain stack trace parsers for existing browsers) but it is inconvenient compared to simple JSON or whatever. On Sep 28, 2014 8:02 AM, "Marius Gundersen" wrote: > It would be helpful if the stack trace was machine readable, not just

Re: Maximally minimal stack trace standardization

But that said an new name and structure would be fine with me. I'm a little worried "stack" would be out of sync with "stack trace" or whatever. Making stack an accesor of "stackTrace" would help but what do we do with writes? On Sep 28, 2014 4:35 PM, "J

Re: Maximally minimal stack trace standardization

represent this structured data. > > Other than that. Great. +1. > On Sep 28, 2014 2:10 AM, "Boris Zbarsky" wrote: > >> On 9/28/14, 1:15 AM, John Lenz wrote: >> >>> * the "stack" property (a string) >>> >> >> I'd somewha

Maximally minimal stack trace standardization

I would like to get see stack traces standardized for ES7, to that end, I would like to define a minimal set of behaviors that would need to be defined: * the "stack" property (a string) * when the stack property is attached (at Error object creation or at throw) * what happens when Error object t

Re: dynamic synchronous import

I would like to see some way to preload everything, and be able to retrieve them synchronously, something like: System.loader.addNoAsync('...'); // throw if all imports aren't available already So that the script could be used during initial render. I understand that this would mean that the m

Re: Function.arguments in JSC

I took a look at Google's internal code index for reference to Function.prototype.arguments and turned up many references to it (PhpMyAdmin, some Intel benchmark, some internal code, etc). This is only code used internally at Google (or was at one time) and not by any means an index of the entire

Re: "import *"

ah, thanks. That makes more sense. On Mon, Sep 22, 2014 at 6:37 PM, Erik Arvidsson wrote: > import * as m from './file.js' > > Imports module instance object. It only creates one binding, m in the > example above. > > On Mon, Sep 22, 2014 at 9:31 PM, John Lenz w

"import *"

As per http://www.2ality.com/2014/09/es6-modules-final.html , "import *" is back (but not in the spec) but I didn't see any discussion about mitigating th

Re: RegExps that don't modify global state?

I wanted to mention the global state of regexs prevent the elimination of otherwise dead code by optimizers. Which is unfortunate. I personally have fixed a number of bugs where a regex overwrote the global state. It is a refactoring hazard. On Sep 17, 2014 8:58 PM, "Viktor Mukhachev" wrote: >

Re: Status/Thoughts on Guards?

Not exactly the same but the Closure Compiler has a "runtime type check" mode that inject type checks. If you write jsdoc type annotations already this can be an low resistance path but its usefulness depends on the accuracy of those annotations. On Aug 21, 2014 6:54 AM, "Curtis Steckel" wrote:

Re: Proposal: generator#clone() and generator#goto()

On Mon, Aug 25, 2014 at 2:17 AM, Salvador de la Puente González < sa...@unoyunodiez.com> wrote: > Sorry, I sent this only to Tab. > > On 20 Aug 2014 17:39, "Tab Atkins Jr." wrote: > > > > > On Wed, Aug 20, 2014 at 5:00 AM, Salvador de la Puente González > > wrote: > > > Hello. > > > > > > Just a

Re: Body-level inner function declarations interaction with the let "temporal dead zone"

It is my understanding that in both cases the declaration are valid but calling inner before "let x" will result in an exception. On Jul 18, 2014 5:34 PM, "Shu-yu Guo" wrote: > Hi all, > > Am I correct in understanding that body-level inner functions hoist both > declaration *and* initialization

Re: ES6 modules (sorry...)

You don't really want 300/3000/3 modules where you have to "load", "parse", then "request (dependencies)". You really need your dependencies, pre-ordered and pre-loaded (that is bundled) if you want your "empty cache" clients to get a good experience. SPYD is only one piece of a puzzle it isn

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

ss.org/topic/functions-as-blocks https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-29.md#function-in-blocks-in-non-strict-mode On Thu, Jun 5, 2014 at 9:51 AM, John Lenz https://mail.mozilla.org/listinfo/es-discuss>> wrote: >* Is there any place that has some concrete ex

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

Or a link to the discussion that led to the content of this section? On Thu, Jun 5, 2014 at 9:51 AM, John Lenz wrote: > Is there any place that has some concrete examples of the different cases > we are trying support with this section (and whether the function is block > scoped or no

Re: In ES6 strict mode: do function declarations within a block hoist?

Thanks. On Thu, Jun 5, 2014 at 8:54 AM, Andreas Rossberg wrote: > On 5 June 2014 17:44, John Lenz wrote: > > That is to say, is this valid: > > > > if (x) { > > f(); > > function f() { doSomething() } > > } > > > > The same question appl

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

Is there any place that has some concrete examples of the different cases we are trying support with this section (and whether the function is block scoped or not in each case)? On Thu, Jun 5, 2014 at 9:45 AM, Allen Wirfs-Brock wrote: > > On Jun 5, 2014, at 8:14 AM, John Lenz wrote:

In ES6 strict mode: do function declarations within a block hoist?

That is to say, is this valid: if (x) { f(); function f() { doSomething() } } The same question applies to class declarations. I assume that top level class declarations hoist. (Where is this in the spec?) ___ es-discuss mailing list es-discuss@moz

Re: for-loops and declaration-like init expressions

Would this still be legal, in this scheme? for ((function x(){}); ;) x // 0 for ((class x(){}); ;) x // 0 On Thu, Jun 5, 2014 at 7:58 AM, Andreas Rossberg wrote: > C-style for-loops allow declarations as init statements, but only some > of them. Yet, the others (function and class) are

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

th that you can't forcing things to always be strict mode. On Thu, Jun 5, 2014 at 7:34 AM, Andreas Rossberg wrote: > On 5 June 2014 16:08, John Barton wrote: > > On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg > > wrote: > >> > >> On 4 June 2014 23:46, Jo

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

On Wed, Jun 4, 2014 at 8:52 PM, Allen Wirfs-Brock wrote: > > On Jun 4, 2014, at 2:43 PM, John Lenz wrote: > > > > > > > > > > > > > How does someone write code to make sure it doesn't fall into legacy > semantics? Unless, I misunderstand th

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

I don't personally want to write sloppy mode code, but there are places you need it (using eval to introduce new symbols into global scope). My interest is writing or support tools that do the "right" thing. On Wed, Jun 4, 2014 at 8:37 AM, Andreas Rossberg wrote: > On 4 Jun

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

On Wed, Jun 4, 2014 at 7:59 AM, Allen Wirfs-Brock wrote: > > On Jun 3, 2014, at 3:12 PM, John Lenz wrote: > > > > > On Mon, Jun 2, 2014 at 9:37 AM, Allen Wirfs-Brock > wrote: > >> >> On Jun 2, 2014, at 6:12 PM, John Lenz wrote: >> >> > &

Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

On Mon, Jun 2, 2014 at 9:37 AM, Allen Wirfs-Brock wrote: > > On Jun 2, 2014, at 6:12 PM, John Lenz wrote: > > > > > > > It seems to imply that existing "sloppy" code that does this is block > scope: > > > > for (let x = 1; x &l

A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations

It seems to imply that existing "sloppy" code that does this is block scope: for (let x = 1; x < 1; x++) { function f() { } store(f); } But this is not (as there is a second definition of f): for (let x = ; x < 10; x++) { for (let y = 1; x < 10; x++) { function f() { } sto

rethrowing exceptions

Has there been any discussion about rethrowing exceptions such that they retain the original context? try { throws(); } catch (e) { if (e instanceof SomeError) { // handle it } rethrow e; } Or is this been out side the spec because stack traces in general are outside the spec? It isn

Re: standardizing Error.stack or equivalent

to include source-maps. The loader has the > right position to obtain the sourcemap from the server or from transcoders. > If we have API on the loader to tell the debugger about the map we can have > a much more flexible solution. > > > On Mon, Mar 31, 2014 at 8:43 AM, John Lenz wro

Re: standardizing Error.stack or equivalent

John did you want to propose an alternative? Maybe: A "name" parameter for inline scripts and eval? This might work for "sourceUrl" but might be limiting for "soureMappingUrl". On Sun, Mar 30, 2014 at 6:25 PM, John Barton wrote: > Hi Mark. I implemented the first sourceURL support, for Fire

Re: standardizing Error.stack or equivalent

sourceUrl works in chrome, with eval at least. Is displayName for function naming? On Mar 28, 2014 11:56 AM, "Sebastian Zartner" wrote: > Hi John, supposedly < >> https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript> >> and < >> http://www

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson wrote: > To be clear. Changing .stack is not an option. We need to introduce a new > API. > > On Tue Mar 25 2014 at 4:40:20 PM, John Lenz wrote: > >> Interesting sourcemap usage. But is there any hope for standardization >

Re: standardizing Error.stack or equivalent

AM, Mark S. Miller wrote: > Hi John, see also my message at < > https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html> > which cites some of your work on sourcemaps. > > > On Tue, Mar 25, 2014 at 11:25 AM, Rick Waldron wrote: > >> >> >&g

standardizing Error.stack or equivalent

I was recently modifying some code to be strict mode compliant and it reminded me that the primary use of the Function caller property and arguments.caller is to build stack traces. Now the latest Internet Explorer releases have support for stack traces, as of course do Chrome, FF, and Safari but

Re: Initializer expression on for-in syntax subject

If we can get uglify and closure compiler to reject it it will go a long way toward making sure it doesn't crop up in the wild. On Mar 14, 2014 10:20 PM, "Brendan Eich" wrote: > Peter van der Zee wrote: > >> >> Which browsers currently don't accept this construct? I wasn't even aware >> that JSC

Re: unicode escapes to for "reserved" identifiers

Awesome thanks. On Feb 11, 2014 5:31 PM, "Allen Wirfs-Brock" wrote: > > On Feb 11, 2014, at 5:11 PM, John Lenz wrote: > > I know this was discussed previously but how did things land (the Nov > notes lead me to think it was undecided)? > Are unicode escapes allowed t

unicode escapes to for "reserved" identifiers

I know this was discussed previously but how did things land (the Nov notes lead me to think it was undecided)? Are unicode escapes allowed to form reserved words, or to form identifiers that would otherwise be reserved? Thanks, John ___ es-discuss maili

  1   2   >