Re: Debuggers and async/await should work together better: I have testcases.

Alex, I asked around, and our debugger folks say that stepping over await should work in current shipping Firefox. Haven't checked out your test case yet, but someone here will. In any case, please do report a bug! Instead of Bugzilla, report it here: https://github.com/devtools-html/debugger.h

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Wed, Nov 29, 2017 at 4:13 AM, pacer...@gmail.com wrote: > Re "..in subscope" and "..relevant"; As repl's can be fixed by > that---all snippets treated as curlybraced. > Hi everyone. For those of you who weren't on this list three years ago, here's the rest of the thread: https://esdiscuss.

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

I think the most straightforward thing is something like this: https://gist.github.com/jorendorff/85d74ef7dce0118664535f84d57d6788 To restate the obvious, this is a minimal fix for your minimized test case, not production code you can take and use. You'd need to implement all the rest of the hand

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

On Tue, May 23, 2017 at 2:44 AM, Alex Vincent wrote: > Full details are at https://github.com/ajvincent/es7-membrane/issues/79 , > which is where I'm hoping to find a solution. > To fix this, you must create a third object for each dry proxy, to serve as its [[ProxyTarget]]. There's no way aroun

Re: ES RegExp parser

> `{type: '+', expression: re}` Sorry, I guess the real expression would be something more like: { type: 'Repetition', expression: re, quantifier: { type: '+', greedy: true } } The point stands. -j On Mon

Re: ES RegExp parser

The second approach, hands down. 1. With the first approach, you're setting up a situation where it's very easy to write buggy analysis code: if you forget to check `re.quantifier` anywhere, your code will run, but you have a bug. Much easier to only have to check `re.type`. 2. If you have a rege

Re: Array tail destructuring

On Tue, Oct 4, 2016 at 7:12 AM, Cyril Auburtin wrote: > I didn't understand everything discussed above, but to me, the only > asymmetry between head and tail destructuring is for infinite iterators: > > `var [x] = neverEndingIterator` vs `var [...a, x] = neverEndingIterator // > fails` > Read th

Re: Re: Proposal: use "One More Point" to handle async functions

On Tue, Sep 27, 2016 at 10:23 AM, Li Xiaolong <898310...@outlook.com> wrote: > 3: the async function calls identically with sync functions, makes it hard > to check out if the function is async without jumping to the definition. > But OMP can easily be recognized. > Usually, async calls will be m

Re: Extended dot notation (pick notation) proposal

On Thu, Sep 22, 2016 at 1:14 PM, Bob Myers wrote: > Sorry for using ALL CAPS. I will not do that any more. You're right: this > proposal DOES (oops, I meant *does*) increase the size of the spec. Is that > the new criteria, that no proposal may increase the size of the spec? > This conversation

Re: Extended dot notation (pick notation) proposal

On Thu, Sep 22, 2016 at 1:14 PM, Bob Myers wrote: > In the proposed "pick/destructure into an object" syntax, I would use > identical destructuring syntax > > ``` > obj.{foo: {bar: {qux}}} > ``` > > which would turn into `{qux: obj.foo.bar.qux}`. > > We are simply using identical destructuring sy

Re: Extended dot notation (pick notation) proposal

On Wed, Sep 21, 2016 at 3:39 PM, Bob Myers wrote: > > Some people on a web site are curious to know if they can reduce 2 > lines of JS code to 1 line > > Right, some people wanted to reduce 2 lines of JS code [...] > That is not historically how JS got destructuring. > But it's a tiny bit more

Re: Extended dot notation (pick notation) proposal

On Wed, Sep 21, 2016 at 12:33 PM, Matthew Robb wrote: > > On Wed, Sep 21, 2016 at 10:40 AM, Jason Orendorff < > jason.orendo...@gmail.com> wrote: > >> Since all new syntax imposes some mental load on all language users, the >> answer should be no unless the benef

Re: Extended dot notation (pick notation) proposal

On Tue, Sep 20, 2016 at 2:38 PM, Bob Myers wrote: > People in the real world continue to wonder why they can't > pick/destructure from objects into objects, instead of just variables. > > http://stackoverflow.com/questions/39602360/es6- > destructuring-reassignment-of-object?noredirect=1#39602360

Re: Symbol.hasInstance and [[Get]] vs [[GetOwnProperty]]

On Mon, Aug 15, 2016 at 8:45 PM, /#!/JoePea wrote: > It seems like using [[Get]] for looking up `@@hasInstance` can be > confusing and requires devs to write extra code. > I think the emotionally loaded words in this post ("fail", "ugly", "fragile", "break") are unhelpful. You have to make your

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

On Tue, Aug 9, 2016 at 3:03 PM, /#!/JoePea wrote: > Why is it that the body of module C is not evaluated before the bodies of > modules A and B? > The module system *does* execute all a module's dependencies before executing that module, *except* in cases like this where there are cycles in the

Re: Static `super` may cause a unwanted "memory leak".

On Tue, Aug 2, 2016 at 3:09 PM, Bergi wrote: > Why would `tmp` be stored as the [[HomeObject]] when the function doesn't > use `super`? In that case a [[HomeObject]] is not needed at all. > To clarify this: of course the JS engine knows whether the code uses `super` or not and can decide to reta

Re: ModuleDeclarationInstantiation behaviour after failure

How about this: Linking happens as eagerly as possible whenever a module arrives off the network. This means that very often we'll be linking one module at a time. In any case, every link set will be a strongly connected component of ready-to-link modules in the dependency graph; and therefore if l

Re: ModuleDeclarationInstantiation behaviour after failure

On Thu, Jul 7, 2016 at 4:33 PM, Allen Wirfs-Brock wrote: > The spec. Only generates errors and does try to define error recovery. > That's up to the implementation. But I would expect implementations to > discard any module records it created during a linking phase that throws > errors. That ma

Re: ModuleDeclarationInstantiation behaviour after failure

On Thu, Jul 7, 2016 at 12:09 PM, Caridy Patiño wrote: > Moving step 7 to the end is not an option since the primary use of that > step is to support circular references. > Not sure this is helpful, but back when I was working with Dave on this stuff, it was supposed to work something like this:

Re: Is it possible to define an array iterator that adjusts to your for-of syntax?

No, it's not possible. Oddly enough, when this functionality was first prototyped in SpiderMonkey many years ago, the iterator protocol *did* pass a boolean to the __iterator__ method (this was before symbols) based on the syntax you were using to unpack the results. This feature was not super use

Re: extending an ES6 class using ES5 syntax?

len Wirfs-Brock wrote: > >> On May 16, 2016, at 10:31 AM, Jason Orendorff >> wrote: >> >> ... >> `B.prototype = Object.create(A.prototype)` is less of a problem, for >> our implementation, because objects created by constructor B later get >> a prototy

Re: extending an ES6 class using ES5 syntax?

In short, cache invalidation is hard. Standard disclaimer: everything below is a radical simplification of what really goes on in a JS engine... When a property access (or equivalently, a method call) happens, the standard says to do a lookup along the prototype chain to find out where the propert

Re: extending an ES6 class using ES5 syntax?

On Sun, May 15, 2016 at 3:07 AM, Andrea Giammarchi wrote: > Thanks Andy, I think that bug has exact same concerns and valid answers for > Boris too. Here it's also the only valid option to properly extend classes > in ES5 and I can't wait for such "warning" to go away, most developers have > been

Re: introduction of statefull functions (inspired by Scala language) - advanced specification of "operator()" for arbitrary objects

The nice thing about @@symbol-named methods is that we *don't* have to extend the Proxy API for them. They're just method calls. This is why there's no hasInstance Proxy trap. `instanceof` basically boils down to a method call, and we already have Proxy traps for method calls: `get` and `apply`.

Re: Take let variable out of temporal dead zone

On Fri, Apr 15, 2016 at 12:52 PM, Oriol Bugzilla wrote: > Is this behaviour intended? Is there any way to take `foo` out of the TDZ, > so that I can assign values and read them? Yes, the behavior is intended. I know because I raised this issue here before the standard was finalized - search the a

Re: Using 'this' in default parameters

On Fri, Jan 29, 2016 at 8:14 AM, ` Mystery . wrote: > IMHO I don't think the default parameters should be evaluated within the > context of the function being called, at least not while it's outside of > function body's region.. Is there a specific reason to do that, or it's > just a design pr

Re: Weak Graph

a transformation pipeline of sorts, maps, and filters just fine. I don't see where lineage or branching comes into any of your examples. I can see how it could, but I think I must be missing something here. > On Fri, 6 Nov 2015 at 17:31 Jason Orendorff > wrote: >> Then it looks a lot

Re: Weak Graph

On Wed, Nov 4, 2015 at 10:09 AM, Jussi Kalliokoski wrote: > I'm trying to come up with a solution to the problem of rendering lists [...] > My idea for a solution is that the lists are immutable, contain a reference > to their parent and a changeset / diff compared to their parent. [...] Good pro

Re: Any reason template string with empty interpolation placeholder (`${}`) throws?

On Thu, Oct 22, 2015 at 7:34 PM, Caitlin Potter wrote: > Okay, but usability wise, this kind of sucks. There's a reason it's not what > people expect, and why other languages with string interpolation behave > differently. Perl and bash both treat "${}" as a syntax error. So does Python's string.

Re: Re: Additional Math functions

On Fri, Oct 9, 2015 at 10:26 AM, Michael McGlothlin wrote: > Why include numbers at all? Some people only manipulate strings so why not > leave numbers to a third-party library that might be better? You can try, but I don't think sarcasm alone is going to get you there. If you want to do somethi

Re: Re: Additional Math functions

On Fri, Oct 2, 2015 at 6:37 PM, Alexander Jones wrote: > What do other languages do? Well, Python's standard library has both a `sum()` builtin and a statistics module. They handle floating-point weirdness differently: >>> sum([1.0, 1e18, -1e18]) 0.0 >>> import statistics >>> sta

Re: Global lexical tier

On Tue, Sep 1, 2015 at 12:03 AM, Allen Wirfs-Brock wrote: > Both the alternative suggest by Jason and the one suggest by Saam were > considered and rejected in these discussions. It's easy to imagine a > different semantics. It's harder to demonstrate that it is a "better > semantics" and to get ag

Re: Global lexical tier

On Aug 31, 2015, at 7:11 PM, Brendan Eich wrote: > > We are in rapid-release hell/heaven. > > This means errata can be issued, and engines can implement the better > resolution for those errata, compared to what the last major-version _de > jure_ spec mandated. Yes. Obviously the bar is very, very

Global lexical tier

Hi everyone. Can we talk about the global lexical tier? This was a mistake, a real blunder. We all should have known better. An extensible intermediate scope implies dynamic scoping. The referent of an identifier can change only once, but it can change. It's like an implicit `with` block around *a

Re: Exponentiation operator precedence

Don't rely on github searches to turn up representative examples. It doesn't work that well. Here's my educated guess as to how ** will be used. The most common use will be to square numbers. a² a**2 Math.pow(a, 2) a.pow(2) Currently you might write `a * a`, which is kind of lame

Re: Exponentiation operator precedence

On Thu, Aug 27, 2015 at 9:04 AM, Kevin Smith wrote: > a**b * -c**d + e I don't think people use unary - like this very often. It's nothing to do with exponentiation. You don't see people write: a * -c + e because the right-side-up way to say that is: e - a * c -j _

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 11:09 AM, Mark S. Miller wrote: > I don't get it. The conflict between > > * the history of ** in other languages, > * the general pattern that unary binds tighter than binary > > seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, > it would be 4.

Re: Exponentiation operator precedence

On Wed, Aug 26, 2015 at 1:03 PM, Thomas wrote: > There's still the issue of exponentiation being right-associative. Unless ** > becomes an operator which behaves differently as to how it would in a high > school maths class, we're at an impasse. I'm not sure I follow. Exponentiation is right-as

Re: Exponentiation operator precedence

On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller wrote: > When the costs were minor, it was ok that the benefits were minor. The costs will probably still be minor if we just let Rick look at it and revise the proposal. What has happened here is - upon implementing the feature, we noticed a probl

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 8:10 PM, Waldemar Horwat wrote: > That has different right and left precedence and is probably the closest to > the mathematical intent. Not to quibble, but I do want to understand: UnaryExpression : PostfixExpression ** UnaryExpression AdditiveExpression : Addit

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff wrote: > What you're describing as "sometimes tighter and sometimes looser" I > would call "the same precedence". It's even easier to specify than the > current proposal: > > UnaryExpressio

Re: Exponentiation operator precedence

On Mon, Aug 24, 2015 at 5:45 PM, Waldemar Horwat wrote: > Let's not. As I said at the last meeting, making ** bind tighter than unary > operators would break x**-2. And making it sometimes tighter and sometimes > looser would be too confusing and lead to other opportunities for precedence > inve

Exponentiation operator precedence

In math, -x² is -(x²), not (-x)². But as proposed for JS, -x**2 is (-x)**2. PHP, Python, Haskell, and D side with the traditional algebraic notation, against JS. Here's PHP: $ php -r 'print(-2 ** 2);' -4 Python: >>> -2 ** 2 -4 Haskell: Prelude> -2 ^ 2 -4 The D grammar

Re: System.import()?

On Tue, Aug 18, 2015 at 1:36 PM, Dave Herman wrote: > The `System.loader.import` feature isn't ready for stabilization yet, and is > blocked on a few other pieces of the Loader design. Well, if it isn't ready, it isn't ready. But can you tell a little bit more? What sort of changes are anticipate

Re: System.import()?

On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck wrote: > This would assume they can support the transformation hooks to do things > like load coffeescript etc. right now, which is the main contention point. It is a perfectly ordinary occurrence in software to ship some capability at one point, and

Re: System.import()?

On Tue, Aug 18, 2015 at 12:11 PM, Domenic Denicola wrote: >> HostResolveImportedModule is widely implemented by compilers, though >> not by browsers. People are writing, using, and sharing ES6 modules today. > > So what is your proposal then? Just standardize the node module resolution > algorith

Re: System.import()?

On Mon, Aug 17, 2015 at 9:50 PM, Bradley Meck wrote: > I think we all want to find a good solution to creating a Loader for ES6 > modules. I would follow WHATWG's Loader if you want to participate. There > are a surprising number of considerations, particularly due to existing code > bases. I'm a

Re: System.import()?

On Mon, Aug 17, 2015 at 5:02 PM, Bradley Meck wrote: > The timing and extensibility is too complex to easily fit into ECMA-262, see > some things mentioned in https://github.com/whatwg/loader/issues/54 . I vote > no for a few years at least. I am not calling for importing the entire loader spec i

Re: System.import()?

On Mon, Aug 17, 2015 at 5:02 PM, Domenic Denicola wrote: >> It's possible to make minor changes to HostResolveImportedModule and >> then specify `System.import` in terms of that. [...] > > I don't understand. If it's in terms of HostResolveImportedModule, and > HostResolveImportedModule is not im

System.import()?

The ES6 module system is taking a real beating in the comments section here: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/ People are concerned about things like: - There is no standard way to load any modules at all in the browser. - There is no standard way for a module to load other

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 3:17 PM, Mark S. Miller wrote: > Just showing the next method: > > function wrap(g, prime) { > let first = true; > return { > next(val) { > if (first) { > first = false; > return g.next(prime); Oh, I see. We can use an intermediate wrapper obj

Re: function.sent beta equivalence?

On Wed, Jun 24, 2015 at 2:17 PM, Brendan Eich wrote: > MM: Libraries could do this. > > yield * wrap(g,function.next); > > MM: "wrap" returns an iterator which wraps the generator which primes the > subgenerator with the supplied value. Thanks for finding this discussion. This is exactly what I

function.sent beta equivalence?

Quick question about function.sent: As of ES6, there's this parallel between functions and generators: // how to wrap a function // f2 is equivalent to f, if f doesn't use `this`. function f(...) { ... } function f2(...args) { return f(...args); } // how to wrap a generator

Re: ES6 Proxy Function Call Trap

On Tue, Jun 9, 2015 at 3:44 AM, Edwin Reynoso wrote: > Alright first I'll say I'm using FF to test because FF supports proxies, and > I really don't know how to use Reflect and how it works yet. FF as well does > not support Reflect right now. Therefore I'll look into that. That's right. Reflect

Re: Look-behind proposal

On Mon, May 18, 2015 at 1:51 PM, Claude Pache wrote: > Another more powerful approach (which I prefer), [...] As long as we prohibit matching groups within lookbehind assertions, I think the approach you prefer is a strict superset of what's proposed. So there's no opportunity cost to taking the

Re: Look-behind proposal

On Mon, May 18, 2015 at 8:50 AM, Nozomu Katō wrote: > I submit a proposal for adding the look-behind assertions to RegExp. Fantastic! I'm not a TC39 member but I've been hoping this would happen for some time. I have often thought that the major obstacle was that no one has done this work. I hop

Re: About generators

On Thu, May 14, 2015 at 2:05 AM, wrote: > Thanks. What is the underlying concurrency framework when we use generators > for concurrent workloads ? Does it depend on the particular VM ? Generators aren't for concurrency. When a generator runs, it runs in the same thread as the caller. The order

Re: Subclassing Function

On Thu, May 7, 2015 at 3:25 PM, Allen Wirfs-Brock wrote: > On May 7, 2015, at 12:50 PM, Francisco Tolmasky wrote: >> In the existing implementations I’ve tried, it appears I can’t do this: >> >> class SuperFunction extends Function { } > > Nope, it's supposed to work. Agreed. We're working on it

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

On Wed, Apr 29, 2015 at 5:41 PM, Andreas Rossberg wrote: >> I'm inferring your comment about generator optimization hardship has to do >> with a function that yields -- whose CFG has multiple entry points and whose >> activation record must live in the heap. > > Yes, the biggest challenge perhaps

Re: super.prop assignment can silently overwrite non-writable properties

On Mon, Apr 20, 2015 at 2:42 PM, Caitlin Potter wrote: > Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the > example case, because the old descriptor is configurable. That’s kind of > weird. Yes, that's it. 9.1.6.3 step 8.a says that writability is checked only if the exis

Re: super.prop assignment can silently overwrite non-writable properties

On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock wrote: >> In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with >> O=X.prototype. > > 4.d.1 doesn't set the property, it just comes up with the property descriptor > to use, if the `Receiver` does not already have a correspondin

super.prop assignment can silently overwrite non-writable properties

We're implementing `super` in Firefox, and ran across this surprising behavior: class X { constructor() { Object.defineProperty(this, "prop", { configurable: true, writable: false, value: 1}); } f() {

Re: Final ES6 Draft

Congratulations, everyone, on this milestone, and thanks for your work. Looking back all the way to ES5, it's striking just how substantial an improvement ES6 is. It'll ultimately affect almost every line of JS code I write. -j On Thu, Apr 16, 2015 at 6:23 PM, Allen Wirfs-Brock wrote: > The fina

Re: Please volunteer to maintain the HTML version of the spec

On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck wrote: > I'm interested. OK, thanks. I'll get back to you next week. Unfortunately I'm not around today. >> Each time a new revision is published, some manual steps are required >> to map broken links to the right sections in the new document. > > Do

Please volunteer to maintain the HTML version of the spec

I need to free up some time to work on other things, so I will not be creating the unofficial HTML version of the spec anymore once ES2015 is final. If you're interested in maintaining the HTML version, let me know! If not, I imagine Allen can use Word to generate HTML versions, so it's not like w

Re: short-circuiting Array.prototype.reduce

On Thu, Mar 26, 2015 at 8:22 PM, Kyle Simpson wrote: > outer = outer.filter(function filterer(inner){ > return inner.reduce(function reducer(prev,current){ > if (prev === false || prev === current) return false; > return current; > }); > }); I think you could write that like this:

Re: Converting strings to template strings

On Mon, Mar 23, 2015 at 1:55 AM, Mark S. Miller wrote: >> String templates are not good for templates, these work only for >> statically defined code and in place meaning you cannot grab content from a >> DB and inject values like names or numbers as you would do with any >> templating system. > >

Re: New ES6 draft - Release Candidate 3, Rev36

The HTML version is up at . Thanks to @caitp, "opt" and parameters (like "[?Yield]") in grammar productions are now shown in color. -j On Tue, Mar 17, 2015 at 7:36 PM, Allen Wirfs-Brock wrote: > Is available at: > http://wiki.ecmascript.org/

Re: Reflect.getOwnPropertySymbols?

On Mon, Mar 16, 2015 at 11:53 AM, Allen Wirfs-Brock wrote: > In ES6, the primary role of the Reflect object is to provide direct access > to an object's essential internal methods: > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-internal-methods-and-internal-slots To further ela

Re: Idiomatic representation of { buffer, bytesRead }

On Wed, Mar 4, 2015 at 3:06 PM, Domenic Denicola wrote: > I thought of that. However, I found it a bit strange that passing this > function a view onto bytes [256, 512] of a 1024-byte buffer would detach the > entire 1024-byte buffer. What do you think? It's a good point. I figured most callers

Re: Class double-bind

I guess we are just going to disagree here. Double bindings with mutability still seem clearly bad. I can't make sense of the rationale that classes can cope with every external binding being mutable except for, somehow, their own name, and we're doing users a favor by "protecting" them from "tampe

Fwd: Class double-bind

Oops, accidentally sent this only to Allen. -- Forwarded message -- From: Jason Orendorff Date: Tue, Mar 3, 2015 at 11:34 AM Subject: Re: Class double-bind To: Allen Wirfs-Brock On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock wrote: > Pretty much everyone I'

Re: Idiomatic representation of { buffer, bytesRead }

On Mon, Mar 2, 2015 at 3:45 PM, Domenic Denicola wrote: > While working on lower-level byte streams we're encountering a number of > situations that need to return something along the lines of `{ buffer, > bytesRead }`. (In this setting "buffer" = ArrayBuffer.) In the most general > form the si

Re: Class double-bind

On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock wrote: > I didn't take the time to come up with a real example. But code within a > class body that refers to the containing class is something I have seem many > times. Some of the most common places you see this is in methods (instance > or

Re: Class double-bind

On Mon, Mar 2, 2015 at 4:15 PM, Allen Wirfs-Brock wrote: > and conversely if we have something like this: > > class Bar { >constructor(n) {this.n=n} >static get const() {return 42); >op(x) { return new Bar(Bar.const )} > }; > > the inner workings of the class would get very screwed up

Class double-bind

Classes are specified to have an immutable inner binding even if they also declare a mutable lexical binding in the enclosing scope: class Foo { foo() { // immutable inner binding 'Foo' is in scope here } } // mutable lexical binding 'Foo' is in scope here

Re: iterator next method returning new object

The most important things here are: 1. Like all performance hacks, unless you've measured a speed improvement under fairly realistic workloads, you shouldn't do this. 2. Whenever you need a custom iterator, try writing a generator instead. It's amazing. You can get the behavior you want in a fr

Re: Automatic iterator.return() in contexts other than for and yield*

On Wed, Jan 14, 2015 at 2:10 PM, Allen Wirfs-Brock wrote: > Yes, there are still a couple of bugs related to this that I hope to get to > before the ES6 spec is totally locked down. Great! Thanks for the quick response. (I felt bad posting about it because I know it's come up before; but I coul

Automatic iterator.return() in contexts other than for and yield*

In some cases a `for` loop will implicitly call `iterator.return()`: function gen() { try { yield 0; } finally { console.log("return was called"); } } for (let x of gen()) throw "fail"; // logs "return was called" This is to support iterators that want to cle

Re: Add Reflect.isConstructor and Reflect.isCallable?

Having said that, I do think Reflect.isCallable and isConstructor would be a fine addition to ES7. These places where we check if an internal method exists feel like a sort of secret-handshake part of the MOP; we should expose them. Any objections? Would someone please add it to the agenda for th

Re: Add Reflect.isConstructor and Reflect.isCallable?

On Tue, Dec 16, 2014 at 3:05 PM, Tom Schuster wrote: > Hello, > > right now there is no way in normal JS code to replicate the IsConstructor > check defined in 7.2.4. function isConstructor(obj) { var p = new Proxy(obj, {construct() { return p; }}); try { new p; } catch (exc)

Re: What would a 1JS-friendly strict mode look like?

AK> I think we should either deprecate one of the modes, or officially support multiple modes and provide a method to switch between them. MM> Feel free to consider sloppy mode deprecated. I do. CP> Well sure, but unfortunately it’s not going to just disappear :( MM> See how much good deprecatin

Re: Removal of WeakMap/WeakSet clear

On Thu, Dec 4, 2014 at 6:58 AM, David Bruant wrote: > Sometimes you call functions you don't have written and pass arguments to > them. WeakMaps are new, but APIs will have functions with WeakMaps as > arguments. I don't see what's crazy. It'd be nice if I don't have to review > all NPM packages I

Re: Removal of WeakMap/WeakSet clear

On Wed, Dec 3, 2014 at 3:54 PM, David Bruant wrote: >> There's something important that's implicit in this argument that I >> still don't have yet. If you were using literally any other data >> structure, any other object, passing a direct reference to it around >> to untrusted code would not only

Re: Removal of WeakMap/WeakSet clear

On Mon, Dec 8, 2014 at 3:46 PM, Tab Atkins Jr. wrote: > On Thu, Dec 4, 2014 at 9:46 PM, Katelyn Gadd wrote: >> I'm surprised to hear that JS runtimes don't necessarily have ways to >> 'hash' a given JS value [...] > > JS has maps/sets that take objects natively, hiding any details about > how a m

Re: Removal of WeakMap/WeakSet clear

On Wed, Dec 3, 2014 at 9:04 AM, David Bruant wrote: > A script which builds a weakmap may legitimately later assume the weakmap is > filled. However, passing the weakmap to a mixed-trusted (malicious or buggy) > script may result in the weakmap being cleared (and break the assumption of > the weak

Re: Removal of WeakMap/WeakSet clear

On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg wrote: > (Back to the actual topic of this thread, you still owe me a reply > regarding why .clear is bad for security. ;) ) I'd like to hear this too, just for education value. -j ___ es-discuss mailing

Re: Removal of WeakMap/WeakSet clear

On Thu, Nov 27, 2014 at 8:58 AM, Andrea Giammarchi wrote: > On Thu, Nov 27, 2014 at 2:44 PM, Andreas Rossberg > wrote: >> Well, there is no functionally correct polyfill for WeakMaps that is >> actually weak, regardless of .clear. > > Please bear with me so I understand your point: if you have `o

String objects should be ordinary

String objects are exotic: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string-exotic-objects Suppose we make them ordinary. No change in behvaior: we can make StringCreate define all the indexed properties on every String object as it's created, right? Wouldn't that be better? It s

Re: Map: filter/map and more

On Mon, Oct 6, 2014 at 1:34 PM, Domenic Denicola wrote: > This is iterables vs. iterators IMO. Iterators are inherently stateful and > I'd expect anything that uses them to consume them, even something named > "map". Iterables of course would not be. I agree. It's inherent in the python-like de

Re: Array.prototype.contains solutions

I'd love to be able to get rid of SHADOWABLE, actually! I just recently found out we can do it with a little rearranging. Extra state-space in property attributes is unavoidable complexity for us. My own preference would be not to standardize it. :) There's also the [Replaceable] attribute in WebI

Re: Throwing errors on mutating immutable bindings

I think there is a way that the error could occur at runtime even in all-strict-mode code: when a new const is added at toplevel in a second script. "use strict"; function f(value) { x = value; } "use strict"; const x = 0; f(1); -j On Wed, Oct 1

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

On Tue, Sep 30, 2014 at 5:35 PM, Andrea Giammarchi wrote: > I'm personally against unmaintained code and/or websites but here it's not > ES7 breaking the web, it's a library already broken (somehow) due native > prototype pollution without a mechanism to prevent these, apparently > historically kn

Re: Having a non-enumerable Array.prototype.contains may not be web-compatible

On Tue, Sep 30, 2014 at 1:45 PM, Michał Wadas wrote: > Bug in MooTools is not a reason to make any method of Array.prototype > enumerable. Well -- true, that would break even more sites. We're backing out Array#contains() for now. It's disappointing to me personally -- that was a volunteer contr

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Sep 30, 2014 at 12:00 PM, Rick Waldron wrote: > My original response questions were poorly asked. I understand the TDZ > semantics, but I couldn't reproduce anything meaningful from your original > example, because I don't have the SpiderMonkey build that includes the let > updates (presum

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js> let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. I guess we can fix this by making the REPL bend the rules of the language. But

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron wrote: > Can you clarify "write"? Does this mean assignment? Yes. > Why would assignment throw? Assigning to an uninitialized variable is an error in ES6. A let-binding is initialized when its declaration is evaluated. So this is OK: let x; //

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock wrote: > On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote: >> Function.prototype.apply, Function.prototype.call, and Reflect.apply >> currently call PrepareForTailCall. Is this a bug? > > No, I don't believe so. Buil

Re: Maximally minimal stack trace standardization

On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock wrote: > I can't imagine what you would want be to try to say about non-EMCAScript > functions. Their internal "call" semantics is determined by the semantics of > their implementation language. Function.prototype.apply, Function.prototype.call,

Toplevel 'let' binding can be left permanently uninitialized after an error

SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the binding 'x' uninitialized. There's no way to get rid of a lexical binding or to initialize it later. The binding is just permanently hosed; any attempt to rea

  1   2   3   4   5   >