Re: Has there ever been discussion around a python-like "with" syntax?

Ron Buckton has a proposal that's quite similar to what you're talking about: https://github.com/tc39/proposal-using-statement On Mon, Oct 15, 2018 at 11:40 AM Dan Aprahamian wrote: > Hello all! First time posting here. I was curious if there was ever talk > about adding something similar to

Re: ECMA site down

There was an issue with the site causing it to be down for maintenance. There's no exact ETA for when it'll be restored, but the hope is that it'll be soon. On Tue, Apr 24, 2018 at 6:29 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Tue, Apr 24, 2018 at 5:24 PM, Michael Theriot

Re: Question of the Day: What about all this asynchrony?

On Wed, Nov 8, 2017 at 7:05 PM, Michael Lewis wrote: > I don't want to break the rules and get removed from the list. But it > seems this list is powered by mozilla, and not "owned" by TC39 anyway. And > because there are no official topic rules, I think that discussing aspects

Re: InterleavedTypedArray type

On Mon, Jul 3, 2017 at 8:10 PM, Steve Fink wrote: > TypedObjects are exactly what you want for this sort of use case, and are > really quite nice. I'm no expert, but TypedArrays probably ought to be > subsumed by the TypedObject spec since AFAICT they are a proper subset of >

Re: Determining if an object can be constructed

It's not, in that it has bugs like all of them. It's obviously unfortunate that the fix for this particular bug hasn't landed yet. On Thu, Jan 19, 2017 at 3:22 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Doh! Good point ... I didn't know Firefox was different from every other >

Re: {}+{} incosistency

On Wed, Apr 13, 2016 at 4:32 PM, Caitlin Potter wrote: > My read of section 12.8.3.1 ( > https://tc39.github.io/ecma262/#sec-addition-operator-plus-runtime-semantics-evaluation > ), > is that V8 is getting this right. > > ToPrimitive on `{}` will, by default, return

Re: Is let let = 1 a valid statement?

On Fri, Nov 13, 2015 at 8:18 AM, Eric Suen wrote: > My bad, I mixd it with esprima, on Chrome and Firefox in loose mode, let > declaration is not support. > so it's syntax error, in esprima, let let = 1 is invalid, but let private > = 1 is valid. > When testing things

Re: Fix Left-Associative Compound Conditional Statements!!

On Thu, Sep 24, 2015 at 4:50 PM, Joseph Groseclose wrote: > Isn't this logic theoretically broken? If any existing code is using it, > the code that is using it is probably performing an invalid or inaccurate > operation and therefore this would only break that code so much

Re: Which behavior is correct (so where should I fill bug report)?

It looks like Babel is taking some invalid shortcuts here. The DestructuringAssignmentEvaluation runtime semantics[1] require the same source object (the parameter `value`) to be used throughout the destructuring operation. Babel compiles the first destructuring into var bar = foo.bar; var qaz =

Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

On Thu, Feb 26, 2015 at 6:48 PM, Katelyn Gadd k...@luminance.org wrote: In the past 'throw' statements have caused a deopt for the enclosing function in v8 and spidermonkey. I think they still do in some scenarios. I would assume that if a statement is able to throw the enclosing function

Re: Performance of iterator .next() as specified

On Mon, Feb 16, 2015 at 7:35 PM, Brendan Eich bren...@mozilla.org wrote: Andreas Rossberg wrote: On 16 February 2015 at 15:41, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: Common pattern is to poll.next() a yield until its `done` property

Re: Can `let`, `static` and `yield` still be used as Identifier?

Gary is right: `let` is disabled for web content in Firefox because our version isn't spec-compatible enough yet. In the shell or chrome code, where it is enabled, our behavior matches traceur's in that we treat the given examples as errors, too. On Fri, Jan 2, 2015 at 4:40 PM, Gary Guo

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

On Thu, Dec 18, 2014 at 6:01 PM, Mark S. Miller erig...@google.com wrote: (1,eval)( + function(){...strict code you want to execute sloppy...})() This doesn't work in SpiderMonkey: stringifying functions retains their strictness, no matter where strict mode is activated. In this case, the

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

On Thu, Dec 18, 2014 at 6:15 PM, Mark Miller erig...@gmail.com wrote: I didn't know that SpiderMonkey did that, but I agree it is better. In light of this news, I'm glad my code sample doesn't work ;). As for would be good for all engines to act the same, the precondition was carefully

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

On Thu, Dec 18, 2014 at 6:50 PM, Felipe Nascimento de Moura felipenmo...@gmail.com wrote: did anyone see my suggestion? (actually, am not sure my e-mails are going out!) Personally(again, my opinion), I think it is at least weird, having a floating string on your code! Specially because(by

Re: Proxies as prototypes

On Sun, Nov 23, 2014 at 11:58 AM, David Bruant bruan...@gmail.com wrote: Le 23/11/2014 07:41, Axel Rauschmayer a écrit : I’d expect the following code to log `GET bla`, but it currently doesn’t in Firefox. That’s because the Firefox implementation of proxies isn’t finished yet, right?

Re: Programmatically controlled template string expansion?

On Tue, Oct 28, 2014 at 1:44 PM, Brendan Eich bren...@mozilla.org wrote: Brendan Eich wrote: safe_html `${x}hello, ${u}/${x}` But you're right, the http://people.mozilla.org/~ jorendorff/es6-draft.html copy I'm finding template in online does not include this prefix form. Did it get cut

Re: Throwing errors on mutating immutable bindings

On Mon, Oct 6, 2014 at 9:22 AM, Isiah Meadows impinb...@gmail.com wrote: Clearly, we still have a long way to go before beating a C++ parser. Pretty interesting to think about, though. This comparison, while quite informative, isn't a full answer to the question at hand, for at least two

Re: Throwing errors on mutating immutable bindings

On Sun, Oct 5, 2014 at 7:24 AM, Isiah Meadows impinb...@gmail.com wrote: If I can find a native parser (that only parses), I would run benchmarks. Shouldn't take that long to time a few rounds of parsing a large library like jQuery or React. I would be more than willing to accept pointers on

Re: Throwing errors on mutating immutable bindings

On Wed, Oct 1, 2014 at 5:39 PM, Mark S. Miller erig...@google.com wrote: On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt oli...@apple.com wrote: JSC does lazy parsing of nested functions and we have no problem reporting static errors, so i’m not sure what you believe is the problem here. Hi

Re: Using Generators in Extended Mode for Co-Routines

On Fri, Sep 12, 2014 at 3:44 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: Generators are not implicit strict. Only modules and classes are. Which is why the example works nicely in Firefox, too. ___ es-discuss mailing list

Re: Fixing the associativity / precedence of the instanceof operator

On Tue, Aug 26, 2014 at 5:48 AM, Charles Pick char...@codemix.com wrote: Ok, what if `!foo instanceof Foo` became a strict mode error instead? That'd increase the difference between the two modes, which is something nobody wants. Also, someone employing strict mode is also quite a bit more

Re: Strawman proposal: new `is` operator

On Tue, Aug 26, 2014 at 3:56 AM, Brendan Eich bren...@mozilla.org wrote: ES4 had 'is' as a type-classifying operator: http://wiki.ecmascript.org/doku.php?id=proposals:is_as_to http://wiki.ecmascript.org/doku.php?id=discussion:is_as_to It would be a mistake to define 'is' without defining

Re: Fixing the associativity / precedence of the instanceof operator

On Tue, Aug 26, 2014 at 3:38 PM, Alex Kocharin a...@kocharin.ru wrote: use developer tools such as linters. Those certainly should warn about code like that. I was trying to find such a tool a few days ago (after similar error was fixed in bunyan), and I found nothing:

Fwd: Questions regarding ES6 Unicode regular expressions

(Forwarding to Norbert as I don't know how closely he follows es-discuss.) -- Forwarded message -- From: Mathias Bynens math...@qiwi.be Date: Mon, Aug 25, 2014 at 10:59 AM Subject: Questions regarding ES6 Unicode regular expressions To: es-discuss es-discuss@mozilla.org

Re: Binding arrow functions.

On Mon, Aug 25, 2014 at 4:30 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/24/14, 10:26 PM, Mark Everitt wrote: The problem remains that arrow functions make bind etc. unpredictable. I think part of Domenic's point is that return values of bind() also make bind (and call/apply for that

Re: Fixing the associativity / precedence of the instanceof operator

On Mon, Aug 25, 2014 at 12:40 PM, Charles Pick char...@codemix.com wrote: Hello, forgive me if this has come up before, I couldn't find any discussions via Google. One regular, annoying mistake I see people making is combining the `!` operator with `instanceof`: if (!foo instanceof

Re: Fixing the associativity / precedence of the instanceof operator

On Mon, Aug 25, 2014 at 1:01 PM, Charles Pick char...@codemix.com wrote: I agree that this could cause some problems, however, that code has never been correct in the first place. It's the equivalent of writing `if (false) {...}`. Seems like it's reasonable to fix something if it only has an

Re: Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls

Do you have any examples of real-world issues caused by this difference? If not, I don't think we should spec the behavior of .sort any more than it is right now. (Well, I'd argue for requiring a stable sort, but then that's easy for me as an implementor working on an engine that already has a

Re: Array.prototype.sort: order and moment of the [[Get]]/[[Set]] calls

On Mon, Aug 18, 2014 at 1:32 PM, Claude Pache claude.pa...@gmail.com wrote: Le 18 août 2014 à 12:59, Till Schneidereit t...@tillschneidereit.net a écrit : Note also that, by my reading of the spec at least, all implementations currently fully adhere to the spec: they [p]erform

Re: WeakMap not the weak needed for zombie views

I largely agree with your arguments, but one point is actually more of a counter argument to having weakrefs: On Mon, Jul 7, 2014 at 10:41 AM, Katelyn Gadd k...@luminance.org wrote: Similarly, it's important to realize that while some use cases for weakrefs are about managing native resources

Re: WeakMap not the weak needed for zombie views

On Mon, Jul 7, 2014 at 11:21 AM, Katelyn Gadd k...@luminance.org wrote: On Mon, Jul 7, 2014 at 2:05 AM, Till Schneidereit t...@tillschneidereit.net wrote: While this is true, I think that, as others have argued in the discussion thread I linked to and elsewhere, weakrefs are a bad solution

Re: WeakMap not the weak needed for zombie views

There is an ES7 proposal for weak references[1] that would satisfy your requirements. However, at least at Mozilla there is very strong opposition to this from people working on the memory management subsystems (i.e. the GC and CC). It's not clear to me that their arguments have been defeated and

Re: WeakMap not the weak needed for zombie views

On Sun, Jul 6, 2014 at 7:45 PM, Filip Pizlo fpi...@apple.com wrote: On Jul 6, 2014, at 9:30 AM, Mark S. Miller erig...@google.com wrote: On Sun, Jul 6, 2014 at 7:47 AM, Katelyn Gadd k...@luminance.org wrote: There are some fairly recent es-discuss threads about weak references. I don't know

Re: Math.TAU

That doesn't mean that you cannot extend builtins - if you don't explicitly load a module into its own Realm using the ModuleLoader, it shares builtins with all other modules. Also note that a Module object isn't the scope for a module script. It's a reflection of the internal metadata about the

Re: 9.1.2 [[SetPrototypeOf]] (V)

On Mon, Jun 30, 2014 at 10:18 AM, raul mihaila raul.miha...@gmail.com wrote: While reading the SetPrototypeOf algorithm I noticed that some steps are repeated. At step 5, if O.[[Extensible]] is false, the method returns false. But at step 8, the same condition is checked again. It seems to me

Re: Standard builtins' prototypes and toString

On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: The spec. current says throw for this Symbol.prototype case. The (reasonable) opposing view is that toString should never throw.

Re: Standard builtins' prototypes and toString

:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 19, 2014, at 3:18 AM, Till Schneidereit wrote: On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 18, 2014, at 4:12 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: The spec. current says

Re: Standard builtins' prototypes and toString

On Thu, Jun 19, 2014 at 8:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 19, 2014, at 10:46 AM, C. Scott Ananian wrote: While we're on the topic, shall we discuss `valueOf()`? Should it get the same treatment? --scott I don't think so. To me, toString is a special case

Re: Standard builtins' prototypes and toString

On Tue, Jun 17, 2014 at 11:27 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote: On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller erig...@gmail.com wrote: I am happy with #b as well, though I prefer #c. I also agree with C. Scott's

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian ecmascr...@cscott.net wrote: On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller erig...@google.com wrote: I like this list. I prefer #c. * We have previously succeeded at making previously non-generic methods generic. I think we could get

Re: Standard builtins' prototypes and toString

On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller erig...@gmail.com wrote: I am happy with #b as well, though I prefer #c. I also agree with C. Scott's interpretation of #c, to mean, appropriate degenerate value, which is generally the zero value, but is plausibly NaN for Date. Whichever

Standard builtins' prototypes and toString

While working on changing Date.prototype to be a plain object in SpiderMonkey, we realized that there's an issue: the way things are specced now, `alert(Date.prototype)` will throw, because `Date.prototype.toString` isn't generic. The same applies for all builtins with non-generic `toString`

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 5:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote: While working on changing Date.prototype to be a plain object in SpiderMonkey, we realized that there's an issue: the way things are specced now, `alert

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 5:55 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/12/14, 11:45 AM, André Bargull wrote: And Number.prototype, String.prototype, Boolean.prototype All of those have the relevant internal fields, so they don't have the problem. e.g. Number.prototype.toString()

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 6:03 PM, C. Scott Ananian ecmascr...@cscott.net wrote: FWIW, in Chrome 36: ```javascript Date.prototype.toString() Invalid Date ({ toString: Date.prototype.toString }).toString() TypeError: this is not a Date object. Number.prototype.toString() 0

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian ecmascr...@cscott.net wrote: On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, I think the current spec. best matches our consensus about changing these prototypes to non-consructor instances. I think my

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 9:30 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote: On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit t...@tillschneidereit.net wrote: On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian ecmascr

Re: Bytecode

On Mon, May 19, 2014 at 3:32 PM, Florian Bösch pya...@gmail.com wrote Far as I see it, the discussion isn't really about bytecode. It's about that you can't quickly/easily tack onto JS everything that's required to make it a good virtual machine you can target from another language. asm.js is

Re: Bytecode

On Mon, May 19, 2014 at 3:46 PM, Florian Bösch pya...@gmail.com wrote: Well, if you're simply going to come up with a bytecode to match JS, then you're gonna have the same kinds of issues that typescript, asm.js, dart, etc. have to target it as a compile target. So if you want to make a VM

Re: Bytecode

On Mon, May 19, 2014 at 3:55 PM, Florian Bösch pya...@gmail.com wrote: So just so I get this straight. You're talking about a bytecode format, which implies some kind of revamped features/VM to run it, but you won't be discussing anything other than ECMAScript as the targeting semantic. Sorry

Re: Array.prototype.last()

On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens mathi...@opera.com wrote: Previous discussion on this topic: http://esdiscuss.org/topic/array-prototype-last We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have

Re: ES6 draft Rev24 now available

On Tue, Apr 29, 2014 at 10:38 AM, Paulo Matos pa...@matos-sorge.com wrote: Thanks. I am new to the list so this might be a recurrent question but is there any working prototype implementation of ES6 that people can experiment language features with? There isn't a complete implementation, no.

Re: Clarify the destructuring syntax

Hi Erop, On Fri, Apr 11, 2014 at 12:35 PM, Егор Николаев termi1...@gmail.com wrote: 1. Should the AssignmentExpression of DestructuringAssignment always to be the Object type? ```javascript let {length} = 123; assert(length, 3); ``` Is this valid? Yes. If it is: 2. Should the

Re: Clarify the destructuring syntax

When in doubt, listen to André when it comes to spec details. So yes, it's valid in Firefox, but invalid per spec. Also, I agree that Firefox's behavior makes more sense, so I hope this'll change. On Fri, Apr 11, 2014 at 1:45 PM, Егор Николаев termi1...@gmail.com wrote: @Till Schneidereit

Re: Shorthand Function declaration

On Wed, Feb 12, 2014 at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Feb 11, 2014 at 12:33 PM, biscotte a la crevette biscottealacreve...@gmail.com wrote: I would like to suggest an alternative function declaration syntax rule : http://pastebin.mozilla.org/4258633 That

Re: SameValueZero comparator and compatibility

On Tue, Feb 4, 2014 at 3:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: This is now bug https://bugs.ecmascript.org/show_bug.cgi?id=2501 I have updated the working draft to normalize -0 keys to +0 in Map.prototype.set and Set.prototype.add The SpiderMonkey implementation does exactly

Re: SameValueZero comparator and compatibility

On Wed, Jan 22, 2014 at 3:53 PM, Brendan Eich bren...@mozilla.com wrote: Andrea Giammarchi wrote: last 3 points are way too much high-level ... ask feature champions other TC39 participants ... how? Just trashing code in test262-discuss? Updating test262 is a good idea, but it's not the

Re: Object.is()

On Mon, Dec 23, 2013 at 1:11 AM, Rick Waldron waldron.r...@gmail.comwrote: On Sun, Dec 22, 2013 at 6:41 PM, Mark S. Miller erig...@google.comwrote: No, Map and Set will equate -0 and +0. In SpiderMonkey's Set and Map: var s = new Set([-0, +0]); s.size; // 2 var m = new Map();

Re: Specifics of `class` and `super`

You could also check the output of Traceur and TypeScript. I don't know how close either of them are to implementing the exact semantics of ES6 classes, but I'm sure it'll be helpful in any case. On Mon, Dec 9, 2013 at 6:28 PM, James Long longs...@gmail.com wrote: I read Allen's email wrong,

Reflecting on object properties

In addition to what Jason just posted about [[OwnPropertyKeys]], I think there are some avoidable inconsistencies in how the various object properties reflection methods are specified. As specified or proposed right now, we have three different such functions: Object.keys,

Re: Extensible typed arrays use case in the wild

Hey Domenic, thanks for bringing this up. IIUC, extensible typed arrays have been decided on, so we will implement them. CCing Niko, who is working on typed arrays and typed objects. On Wed, Nov 27, 2013 at 2:56 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I found this relevant to

Re: Typed Objects / Binary Data Polyfills

On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd k...@luminance.org wrote: Are there any known-good polyfills for the current draft Typed Objects / Binary Data spec? I want this, too, and will start working on it soon-ish if nobody else does or already did. Presently, JSIL has a set of primitives

Re: Typed Objects / Binary Data Polyfills

. Dmitry On Sun, Nov 17, 2013 at 2:04 PM, Till Schneidereit t...@tillschneidereit.net wrote: On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd k...@luminance.org wrote: Are there any known-good polyfills for the current draft Typed Objects / Binary Data spec? I want this, too, and will start working

Re: Proposal to simplify Generators impact

On Sun, Oct 27, 2013 at 1:59 AM, Lucio Tato luciot...@gmail.com wrote: yield*(curr); Note that, in difference to `function* foo`, that is valid ES5. In fact, I bet there is real code along the lines of `yield*(time - offset)` out there. ___

Re: [[Invoke]] and implicit method calls, once more

On Fri, Oct 18, 2013 at 8:06 PM, Brandon Benvie bben...@mozilla.com wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 6:45 PM, Kevin Smith zenpars...@gmail.com wrote: This is trivial with Symbols: let shuffle = Symbol(); Array.prototype[shuffle] = function() {...}; Only code that has access to the `shuffle` symbol may use the method: let shuffled = array[shuffle]();

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich bren...@mozilla.com wrote: Benjamin (Inglor) Gruenbaum wrote: However, this is considered bad practice for many reasons I don't have to repeat here (what if other libraries also override it? What if some user code? What if it makes it to the

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich bren...@mozilla.com wrote: Till Schneidereit mailto:t...@tillschneidereit.net October 13, 2013 11:28 AM And now it causes problem for TC39, browser vendors, sites that use it and end users. (The last group should be affected the least because

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 11:50 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Benjamin (Inglor) Gruenbaum not to mention stuff like `.map` or `.reduce` would still return an Array which would result in more

Re: [[Invoke]] and implicit method calls

On Wed, Sep 25, 2013 at 10:58 AM, Tom Van Cutsem tomvc...@gmail.com wrote: 2013/9/24 Brendan Eich bren...@mozilla.com Brandon Benvie mailto:bben...@mozilla.com September 24, 2013 11:44 AM It seems unfortunate that we have to rely on a membrane for something as simply as `new Proxy(new

Re: [[Invoke]] and implicit method calls

On Wed, Sep 25, 2013 at 3:31 PM, Tom Van Cutsem tomvc...@gmail.com wrote: 2013/9/25 Till Schneidereit t...@tillschneidereit.net Note that .invoke is not in that part, though: once proxies ship (in more than one browser) with all method calls invoking the .get handler, that ship has sailed

Re: [[Invoke]] and implicit method calls

On Wed, Sep 25, 2013 at 4:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 25, 2013 at 8:18 AM, Till Schneidereit t...@tillschneidereit.net wrote: Note that .invoke is not in that part, though: once proxies ship (in more than one browser) with all method calls invoking the .get

Re: [[Invoke]] and implicit method calls

On Tue, Sep 24, 2013 at 4:49 PM, Mark S. Miller erig...@google.com wrote: I would have no objections to dropping it. For me, the Invoke trap is merely another derived trap whose main use is to avoid allocations needed when relying only on more fundamental traps. See

Re: [[Invoke]] and implicit method calls

On Tue, Sep 24, 2013 at 8:38 PM, Brendan Eich bren...@mozilla.com wrote: Based on all the great input (thanks to André for his summary, and Mark for pointing out works always beats half-works/half-broken), and talking to Allen 1:1, I'm back to status quo ante: we are better off being

Re: [[Invoke]] and implicit method calls

and fans willing to write SpiderMonkey-specific code (or who wrote it in the past, possibly a while ago, and who want to keep it going). /be Till Schneidereit mailto:till@tillschneidereit.**nett...@tillschneidereit.net September 24, 2013 11:53 AM Based on all the great input (thanks

Re: [[Invoke]] and implicit method calls

On Mon, Sep 23, 2013 at 10:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote: Indeed, there are trade-offs and there is no silver bullet. The status-quo, which I advocated, entails: - we keep the invoke() trap, with its current signature: invoke(target, propertyName, argsArray, receiver) -

Re: [[Invoke]] and implicit method calls

(sending from the right address this time, with apologies for the double post to the CC'd people.) On Wed, Sep 18, 2013 at 6:56 PM, Brendan Eich bren...@mozilla.com wrote: David Bruant mailto:bruan...@gmail.com September 18, 2013 12:52 PM Why? (damned! how do I find myself defending invoke

Re: Continuing woes in reading the ES6 spec language

On Thu, Sep 12, 2013 at 11:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 12, 2013, at 1:50 PM, Brendan Eich wrote: I thought we agreed with Andreas Rossberg's proposal to isolate default expressions from hoisted body declarations, as if (kind of) desugaring Damned if I

Re: [[Invoke]] and implicit method calls

On Thu, Sep 12, 2013 at 2:35 PM, Tom Van Cutsem tomvc...@gmail.com wrote: 2013/9/12 Till Schneidereit t...@tillschneidereit.net I agree, anything else would be surprising. But can't we make the .invoke trap work for both [[Invoke]] and [[InvokeConditional]]? It would just always be called

Re: [[Invoke]] and implicit method calls

for these corner cases in the majority of cases, and quite deliberately so in the others, this seems fine to me. /be Till Schneidereit wrote: I'm beginning to like a conditional option on [[Invoke]]. Consider: [[Invoke]](P, ArgumentsList, Receiver, conditional=false) If conditional

Re: [[Invoke]] and implicit method calls

On Thu, Sep 12, 2013 at 12:38 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Sep 11, 2013 at 9:08 AM, Tom Van Cutsem tomvc...@gmail.com wrote: Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor to [[Has]] + [[Invoke]] in general, because [[Has]] will

Re: [[Invoke]] and implicit method calls

On Tue, Sep 10, 2013 at 1:23 AM, Jason Orendorff jason.orendo...@gmail.comwrote: On Mon, Sep 9, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I'll take a look at it. My first reaction is that this sounds like a good idea. A lot more can be found by searching for

Re: [[Invoke]] and implicit method calls

On Tue, Sep 10, 2013 at 1:31 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Note that determining desired pattern is relevant to the new DOM promises design (tracking this at https://github.com/domenic/promises-unwrapping/issues/25). Omitting a few steps not relevant to the issue

Re: [[Invoke]] and implicit method calls

On Tue, Sep 10, 2013 at 5:03 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 10, 2013, at 3:55 AM, Till Schneidereit wrote: When implementing the [[Invoke]] trap in SpiderMonkey, I went with the assumption that it should apply to all calls of the forms `receiver.fun

Re: [[Invoke]] and implicit method calls

On Tue, Sep 10, 2013 at 7:45 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Tue, Sep 10, 2013 at 11:11 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Having to create a new bound function on every method call seems too expensive. Only for proxy method calls, and it's easily

Re: [[Invoke]] and implicit method calls

On Tue, Sep 10, 2013 at 8:35 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 10, 2013, at 10:45 AM, Jason Orendorff wrote: On Tue, Sep 10, 2013 at 11:11 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Having to create a new bound function on every method call seems too

Re: Logical operators don't use valueOf()

On Sun, Sep 8, 2013 at 2:15 AM, Marius Gundersen gunder...@gmail.comwrote: That's the way ToBoolean has always been defined http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.2 . All objects are considered to be Boolean true values. So does this mean I can override toBoolean to

Re: 'function *' is not mandatory

On Sun, Sep 1, 2013 at 2:43 AM, Brendan Eich bren...@mozilla.com wrote: Lots of constructors/factories out there. An essential (see Aristotle) argument for why function* for generator syntax (ignoring trumping reasons 12) must say why *this* particular factory needs special (a la function*)

Re: Lexical scoping of 'function' in sloppy mode breaks legal ES5

On Mon, Aug 19, 2013 at 7:20 PM, Andreas Rossberg rossb...@google.comwrote: On 19 August 2013 19:02, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Does V8 crash on the simpler example? Does it produce a ReferenceError (not conforming to ES5) on the call to g()? You're implementation may be

Re: Why not private symbols?

On Wed, Jul 31, 2013 at 6:21 PM, Dean Landolt d...@deanlandolt.com wrote: That leaves default non-enumerability. Consider the fact that object literal methods are enumerable. Why should choosing a unique name as opposed to an identifier for a method have any bearing on enumerability? I

Re: Proxy-for-array transparency issues

On Tue, Jul 30, 2013 at 10:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I was really asking about purpose of application level Array.isArray tests. What is the application really asking when it uses that test? Is it really asking array-like? What counts as array-like? My guess is:

Re: Proxy-for-array transparency issues

On Wed, Jul 31, 2013 at 12:19 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 30, 2013, at 2:21 PM, Till Schneidereit wrote: On Tue, Jul 30, 2013 at 10:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I was really asking about purpose of application level Array.isArray

Array.prototype.values breaks the web

We've had to back out Array.prototype.values for the second time now, because it breaks every website that uses Sencha's Ext.js. See [1], [2] and [3]. In [4], Don from Sencha says that they're investigating, but also that even once they fix the issue, (obviously) it's going to take some time for

Re: [idea] One more call operator

On Sun, Jul 21, 2013 at 12:17 AM, Andrew Fedoniouk n...@terrainformatica.com wrote: Unfortunately setters do not work with jQuery where chained calls are used frequently: el.myplugin({}) .addClass(myplugin); that with new syntax may look like as: el.myplugin: { params }

Re: [idea] One more call operator

On Sun, Jul 21, 2013 at 12:44 AM, Rick Waldron waldron.r...@gmail.comwrote: On Sat, Jul 20, 2013 at 6:27 PM, Till Schneidereit t...@tillschneidereit.net wrote: On Sun, Jul 21, 2013 at 12:17 AM, Andrew Fedoniouk n...@terrainformatica.com wrote: Unfortunately setters do not work

Re: Object literal syntax for dynamic keys

On Fri, Jul 19, 2013 at 5:11 PM, Kevin Smith zenpars...@gmail.com wrote: Sure - page 129 of the latest draft: ComputedPropertyName : [ AssignmentExpression ] 1. Let exprValue be the result of evaluating AssignmentExpression. 2. Let propName be GetValue(exprValue). 3.

Re: Frozen Date objects?

On Thu, Jul 18, 2013 at 1:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie bben...@mozilla.com wrote: On 7/17/2013 4:36 PM, Jonas Sicking wrote: Is this simply a SpiderMonkey bug? Do we expect JS code to be able to handle Date objects

Re: Array.prototype.find() (and probably findIndex()) compatibility hazard

I forgot to follow up on this: the issue in Asana was fixed on their side last week. We haven't received any other reports of sites these methods are causing issues for, so it's looking pretty good so far. On Fri, Jul 5, 2013 at 8:38 PM, Till Schneidereit t...@tillschneidereit.net wrote

Re: [proposal] Function calls, syntax sugar

On Sat, Jul 13, 2013 at 10:49 PM, Andrew Fedoniouk n...@terrainformatica.com wrote: OK, what about this definition then [name] [no LineTerminator here] [literal object declaration]; So this: foo.bar { one:1, two:1 }; will be parse as a method call: foo.bar {one:1,two:1}; And

  1   2   >