Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

Template is transitively frozen, so it cannot be mutated in place. On Wed, Jan 9, 2019 at 11:49 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Wed, Jan 9, 2019 at 7:40 PM Andrea Giammarchi > wrote: > > I dare saying tags are another issue here, 'cause "abc" === "abc", > > and

Re: String identity template tag

I think this is the right question. I agree that String.cook or whatever it is called with typically be called explicitly rather than used syntactically as a tag. However, putting the optional mapping function aside for a moment, if the job it is doing is equivalent to that done by a tag function,

Re: String identity template tag

I like String.cooked best. While I agree that method names should generally be verbs, I suggest this rule should *not* be used for template literal tag names. Rather, the tag name should generally be descriptive, naming the language being parsed or the way it is interpreted or what the value of

Re: String identity template tag

d behavior. I just never would have thought to describe that behavior as "expanding" something. What is it expanded into? > On Wed, Dec 12, 2018 at 20:21 Mark Miller wrote: > >> What is the intuition behind "expand"? What is being expanded, and what >>

Re: String identity template tag

What is the intuition behind "expand"? What is being expanded, and what is it expanding into? On Tue, Dec 11, 2018 at 10:59 PM Isiah Meadows wrote: > Those names a little too generic for my liking here. What about > `String.expand(template, ...params)`? > > And also, let's not try to bake a

POLA Would Have Prevented the Event-Stream Incident

The npm / event-stream incident is the perfect teaching moment for POLA (Principle of Least Authority), and for the need to support least authority for JavaScript libraries. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 by Kate Sills (cc'ed) explains

Re: Module Namespace Objects - "writable"

Ah. Crossed in the mail. Yes, Alan raises the same issues regarding the TDZ vs non-writable worry. Thanks for the pointer. On Wed, Oct 24, 2018 at 11:01 AM Logan Smyth wrote: > Here's one other post about this from Allen: > https://github.com/tc39/ecma262/issues/749#issuecomment-265637923 > >

Re: Module Namespace Objects - "writable"

Extremely good! But it is more than just a "should" or "sensible". It is a requirement of the object invariants. If a property is described as a non-configurable non-writable data property, it must always have the same value. One issue I think should be open to debate: If the exported variable

Re: Proxy target/handler access leak in Node

> The Node.js trust model assumes that all code is trusted. First I want to respond to this sentence out of context. I often hear such phrases. I know what people mean by this, but the phrase "trusted" here *always* leads to confusion and muddy thinking. I don't trust the code I wrote yesterday.

Re: Proxy target/handler access leak in Node

On Mon, Sep 17, 2018 at 8:32 AM Darien Valentine wrote: > Thanks for the context, James. Yes, this thread mainly concerns the issue > of being able to obtain references to values within the handler/target from > external code, though I did try to make a case for not having the showProxy > option

Re: Proxy target/handler access leak in Node

This is indeed quite scary. I have never used of explored the Node `util` API. What is going on here? Can you explain? The Realms shim and SES (which build on the Realms shim) create an environment in which only those globals defined by EcmaScript, not by the host, are present by default.

Re: Symbol history

There was at some point an attempt at elaborating "symbol" into some kind of "private name" or "private symbol", which failed for well explained reasons. However, this is not where symbols started. Symbols started as a way to introduce new properties while avoiding conflict with possible property

Re: Proposal: Add a global Infinitesimal property

See the entire thread at < https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks>. While this position is in no way official, several of the reactions on the thread are from other committee members, and so serves as an indication of

Re: Number.MAX_SAFE_INTEGER incorrect?

n "operate on or with" I'd say the rfc is correct. But the language is ambiguous and should be clarified. On Sun, May 6, 2018 at 12:34 PM, Mark Miller <erig...@gmail.com> wrote: > Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript > spec is corr

Re: Number.MAX_SAFE_INTEGER incorrect?

Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript spec is correct. 2**53 is indeed exactly representable, which is what the rfc is about. But 2**53 is not safe, which what the ecmascript spec is about. On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren <

Re: Number.MAX_SAFE_INTEGER incorrect?

Oops. Should be: if (isSafeInteger(a) && isSafeInteger(b)) { const c = a + b; if (isSafeInteger(c)) { // c is actually the sum of a and b } } ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Number.MAX_SAFE_INTEGER incorrect?

motivation: if (isSafeInteger(a) && isSafeInteger(b)) { const c = a + b; if (isSafeInteger(b)) { // c is actually the sum of a and b } } On Sun, May 6, 2018 at 10:57 AM, Logan Smyth wrote: > To clarify, the "you can still add one to them" is probably the most

Re: Web Security Puzzles with a TC39 agenda

Hi Mike, your message end with "In case you’re interested in how the puzzles tie into the larger point I’m trying to make:" followed by three unexpandable dots. Copy/paste error? (Needless to say, I am interested ;).) On Mon, Apr 30, 2018 at 8:02 AM, Mike Samuel wrote: >

Re: Set functions

Yes, please do! On Tue, Apr 10, 2018 at 8:45 AM, Sebastian Malton wrote: > I know that this has been brought up before but nothing seems to have come > up with it. It also has had a lot of enthusiasm about it. Would me writing > up a new proposal for adding the following

Re: Function composition vs pipeline

On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband wrote: > As someone who does wear the shoes of a senior programmer responsible > (along with my team) for overseeing a very very large web project, the > super trivial and easy answer to this is "use a linter" - eslint can be >

Re: try/catch/else

Hi Claude, that's nice. Whenever I faced this issue I always turned to the boolean flag variable. But this is strictly better. I expect to use it from now on. Thanks! On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache wrote: > What about the following pattern (labelled block

Performance of frozen vs non-frozen objects

At https://github.com/airbnb/javascript/issues/1619#issuecomment-353972202 I wrote: I tried https://jsperf.com/freeze-vs-seal-vs-normal/3 and > https://jsperf.com/freeze-vs-seal-vs-normal/28 on Chrome, FF, and Safari. > I don't know why the bar charts are not updating. I am traveling and do not >

Re: Add new function waitFor

On Fri, Nov 17, 2017 at 1:50 PM, Michał Wadas wrote: > For me it boils down to "implementations which already don't follow spec > exactly won't be able to implement such new part of specification"... > > Dynamic code generation with access to existing scope (sloppy mode

Re: Observable GC

There is a glaring inconsistency in the criteria we use to evaluate these issues. While we are understandably reluctant to admit more non-determinism into the platform via weakrefs, we have admitted an astonishingly greater degree of non-determinism into the platform via "Shared Array Buffers"

Re: Proxy performance: JIT-compilation?

So from y'all's various implementation perspectives, how does https://github.com/tvcutsem/es-lab/issues/21 look? Do you think it would make it easier to achieve much higher performance proxies than we could without these subtle semantic changes? Or do you think we can as easily achieve these

Re: Proxy performance: JIT-compilation?

Alex, I'll just point out that you are already engaged in the best kind of activity to get implementors to optimize these paths: Building a membrane library that can get widespread use, which encapsulate the complexity of proxies behind a more usable API, for which these proxy operations are the

Re: getOwnPropertyDescriptor side effects

On Thu, Jan 19, 2017 at 10:52 AM, Mark S. Miller wrote: > > > On Thu, Jan 19, 2017 at 9:30 AM, Boris Zbarsky wrote: > >> On 1/19/17 12:24 PM, Isiah Meadows wrote: >> >>> 1. What does Firefox do with the getter on non-errors? >>> >> >> Oh, I didn't make that

Re: Object.freezing proxies should freeze or throw?

On Tue, Aug 9, 2016 at 10:58 AM, doodad-js Admin wrote: > I think too much validation is not a good idea. Let the proxy lie. If you > don't, what is the purpose of Proxy? http://research.google.com/pubs/pub40736.html Of course, we can still agree that too much, by

Re: Observing whether a function is strict

I don't get it. What is being removed? What purpose does this accomplish? On Thu, May 26, 2016 at 4:03 PM, Claude Pache wrote: > > Le 26 mai 2016 à 13:23, Mark S. Miller a écrit : > > > > On Thu, May 26, 2016 at 11:25 AM, Claude Pache

Re: Do await statements unblock synchronously?

. Btw, I assume your "tick" is equivalent to our "turn" or "job". Tick is not bad but neither is it clearly better. We should not introduce a third term since we already have more than we need. > > On Mon, Apr 11, 2016 at 1:36 PM, Mark Miller <erig...@gmail.com

Re: Do await statements unblock synchronously?

On Mon, Apr 11, 2016 at 9:31 PM, Mark S. Miller wrote: > Not necessarily "the next tick", but some future tick. Definitely not in > this tick or the tick in which the promise is resolved. > Meant: "or the tick in which the promise is settled." > Definitely in its own

Re: Error stack strawman

On Wed, Feb 17, 2016 at 5:36 PM, Gary Guo wrote: > * isTail will be set when the frame indicates a frame created by tail call > instead of normal function call. Caller's frame is already removed so we > need some indication for that to help debugging. > Nice > > * For

Re: Calling toString on function proxy throws TypeError exception

Non-membraned proxies are irreparably non-transparent. This case is not worth worrying about. On Tue, Oct 27, 2015 at 1:05 PM, Claude Pache wrote: > > > Le 27 oct. 2015 à 15:52, Mark S. Miller a écrit : > > > > Notice that whatever we decide on the

Re: Calling toString on function proxy throws TypeError exception

Only because typeof f === 'function' divides the world into callables and non callables. On Oct 26, 2015 3:20 PM, "Allen Wirfs-Brock" <al...@wirfs-brock.com> wrote: > > > > On Oct 26, 2015, at 11:20 AM, Mark Miller <erig...@gmail.com> wrote: > > >

Re: Calling toString on function proxy throws TypeError exception

I like the idea a function proxy is more encapsulating of its implementation than a function is. I also like the idea of treating a function proxy as a builtin callable, rather than a function written in JS, and return something like "function () { [function proxy] }" as Tom suggested or

Re: Calling toString on function proxy throws TypeError exception

Ok, that all makes sense and is fine with me. Thanks for clarifying. Tom, I'm still curious what you remember? On Thu, Oct 22, 2015 at 2:59 PM, Allen Wirfs-Brock wrote: > > On Oct 22, 2015, at 11:43 AM, Mark S. Miller wrote: > > I know that's true

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

On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter wrote: > Cute, but nobody is realistically going to do that. > Since `${}` is a static error, what do you realistically think people will do? Especially if they meant `${''}`, how do you expect them to react to the static

Re: memory safety and weak references

At https://esdiscuss.org/topic/memory-safety-and-weak-references#content-1 Dave Herman wrote > Interestingly, I wonder if the idea of only collecting weak references > between turns is immune to such attacks, since it's not possible to > have a bogus reference on the stack between turns, where

Re: Please help with writing spec for async JSON APIs

+1 for line delimited JSON. It would be good to switch all users of json-seq over to it and to deprecate json-seq. Perhaps an RFC would help. On Mon, Aug 3, 2015 at 11:53 PM, Bruno Jouhier bjouh...@gmail.com wrote: RFC 7464 has a different format (0x1E at beginning of every record) and a

Re: Generalize do-expressions to statements in general?

On Mon, Jul 13, 2015 at 6:53 PM, Isiah Meadows impinb...@gmail.com wrote: To be perfectly honest, though, I'm not entirely sure the specifics of the do-expression proposal, since Google is failing me here (can't find a thing giving more detail than this mailing list). And as for what my

Re: Template site objects and WeakMap

Hi Yusuke, congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel, and very surprising. I have been working

Re: RegExp.escape()

Perhaps. I encourage you to draft a possible concrete proposal. On Sat, Jun 13, 2015 at 11:30 AM, Jordan Harband ljh...@gmail.com wrote: Would it help subclassing to have the list of syntax characters/code points be on a well-known-symbol property? Like `RegExp.prototype[@@syntaxCharacters]

Re: PerformPromiseAll

On Wed, Jun 10, 2015 at 7:37 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 9, 2015, at 9:53 AM, C. Scott Ananian wrote: On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller erig...@google.com wrote: Do you ever test that the object returned by `Promise#timeout(n)` is something

Re: Ideas on type hinting and named parameters

On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison lbljef...@gmail.com wrote: Instead, the purpose of initializers outside of the constructor are to increase expressivity in a different sense than what I think you meant about constructor initialization: It allows initialization that isn't based

Re: Fixing `Promise.resolve()`

Independent of the current issue, I just want to go on record stating that dynamically scoped variables are a cure worse than any disease we might think to apply them to. Avoid at all costs. On Wed, Jun 10, 2015 at 8:44 AM, C. Scott Ananian ecmascr...@cscott.net wrote: I don't agree that

Re: When the only tool you have is subclassing, all extensions look like....

I don't understand your answer. p and r are plain promises. They must be because they exist before q does. q is the first remote promise in this scenario. How does resolving r to q leave r unsettled but give q access to the messages buffered (and to be buffered) in r? I think the answer must

Re: Subclassing ES6 objects with ES5 syntax.

Just to close the loop on this, regarding the main point I remain convinced and would be happy to champion. Again, thanks for pushing on this. More later -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org

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

Yes. The problem is not that DefineOwnProperty is not acting more like assignment. The problem is that super.prop = x; is acting too much like DefineOwnProperty and too little like assignment. On Tue, Apr 21, 2015 at 3:54 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 20, 2015, at

Re: Putting `global` reference in specs

This is one of several cases where, post ES6, we can provide a std module import that provides a built-in that carries authority. Another example is the constructor for making weak references, which necessarily provide the ability to read a covert channel. As with shadowable globals, this module

Re: Converting strings to template strings

The pattern [\S\s]*? admits a lot. Why are you confident that it can't contain a string that, for example, closes the function with an unbalanced }, then has an evil expression which evaluates, followed by an unbalanced { so the whole thing still parses? On Sun, Mar 22, 2015 at 7:38 AM, Andrea

Re: Module import/export bindings

Story is way too simple. JS const means constant, unchanging. By contrast, import bindings, like const in C++, means read-only view. This is *very* different from constant. Don't use the const analogy when changes are still observable. On Mon, Mar 16, 2015 at 9:20 AM, Allen Wirfs-Brock

Re: Maximally minimal stack trace standardization

On Wed, Mar 11, 2015 at 6:31 PM, John Lenz concavel...@gmail.com wrote: I'll retract that suggestion having tried to write an argument for it. Thanks. It sad though, removing stack isn't really an option. a) It has never been added, in the sense that it does not appear in the std. b)

Re: Class double-bind

Hi Kevin, If it were just a question of non-const-classes being too mutable, well, they're everywhere already ridiculously too mutable in line with most things in JS. It would be coherent to wait for const classes to repair the mutability of the binding at the same time it repairs the mutability

Re: Proposal: Additional Meta Properties for ES7

On Mon, Mar 2, 2015 at 9:30 AM, John Lenz concavel...@gmail.com wrote: 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

Re: Proposal: Additional Meta Properties for ES7

On Mon, Mar 2, 2015 at 10:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 2, 2015, at 9:30 AM, John Lenz wrote: 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

Re: Function name property

Why do arrow functions need to reflect on themselves? I think it is more useful for all code directly inside a non-arrow function to be able to reflect on that non-arrow function. If I wrote an arrow function and then found I wanted it to reflect on itself, I'd be happier rewriting it as a

Re: Global method calls

of the realm of their creation, and use that. Besides throw, any other answer would be too much magic and (at least) hard to explain. Also, this aligns with the global capture of sloppy functions. On Sun, Feb 22, 2015 at 2:05 PM, Domenic Denicola d...@domenic.me wrote: From: Mark Miller [mailto:erig

Re: Global method calls

On Sun, Feb 22, 2015 at 1:03 PM, Domenic Denicola d...@domenic.me wrote: (Cc'ing public-script-coord in case this answer gets more complicated in the presence of the window proxy/overriden this-in-global setup.) Given code like script addEventListener(foo, function () { });

Re: Global method calls

Denicola Sent: Sunday, February 22, 2015 16:39 To: Mark Miller Cc: public-script-co...@w3.org; es-discuss@mozilla.org Subject: RE: Global method calls Thanks Mark. At this point it may tend toward more of a public-script-coord question... From: Mark Miller [mailto:erig...@gmail.com

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer a...@rauschma.de wrote: However, you can’t freeze `Array.prototype` We do. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: @@toStringTag spoofing for null and undefined

On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows impinb...@gmail.com wrote: From: Mark S. Miller erig...@google.com To: Gary Guo nbdd0...@hotmail.com Cc: es-discuss@mozilla.org es-discuss@mozilla.org Date: Sat, 24 Jan 2015 07:11:35 -0800 Subject: Re: @@toStringTag spoofing for null and

Re: @@toStringTag spoofing for null and undefined

Actually, I withdraw that last sentence. Such protections are relevant as well in some specialized circumstances in which the trusted code runs first and squirrels away the relevant primordials such as Object.prototype.toString before it can be corrupted. Extra care is needed to avoid using it

Re: @@toStringTag spoofing for null and undefined

Put better, the spec requires that Object.freeze(Object.prototype) works. On Sat, Jan 24, 2015 at 2:57 PM, Mark Miller erig...@gmail.com wrote: On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows impinb...@gmail.com wrote: From: Mark S. Miller erig...@google.com To: Gary Guo nbdd0

Re: JavaScript 2015?

JavaScript X === EcmaScript Y :- X === Y + 2009 Y = 6; On Thu, Jan 22, 2015 at 4:17 PM, Brendan Eich bren...@mozilla.org wrote: Andrea Giammarchi wrote: I really don't understand ... I'm pretty sure you do understand -- you just don't like it. The annual cycle may fail, but that would

Re: @@toStringTag spoofing for null and undefined

On Wed, Jan 21, 2015 at 12:51 PM, Jordan Harband ljh...@gmail.com wrote: To reiterate, I see the issue as boiling down to two questions: 1) Should builtins have their @@toStringTag value configurable? Can anyone provide a use case, or any value, to allowing this? If not, I think they should

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

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 crafted so that engines did not need to retain the original source, but rather,

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/4/14, 1:36 PM, Travis Leithead wrote: Note that window is not the global. It's a proxy whose target is the global. Yes, but within a browser UA, there is no way to get a reference to the naked global because all

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/4/14, 4:45 PM, Mark Miller wrote: On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: Sure, for a scope chain. Testcase at https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

Yes. I was glad to find in that message a pointer back to https://mail.mozilla.org/pipermail/es-discuss/2012-December/027114.html On Tue, Dec 2, 2014 at 5:36 AM, David Bruant bruan...@gmail.com wrote: Le 02/12/2014 14:24, David Bruant a écrit : Hi, I feel like I've been in an equivalent

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On Sun, Nov 30, 2014 at 6:12 PM, Mark S. Miller erig...@google.com wrote: [...] Put another way, if this invariant is preserved by WindowProxy, then Should be: is not preserved by or is violated by anyone else seeking to create another object that violates this invariant can create a Proxy

Re: Eval, literal eval, safe eval

On Sun, Nov 23, 2014 at 8:22 AM, Mark S. Miller erig...@google.com wrote: https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/ http://research.google.com/pubs/pub40673.html https://code.google.com/p/google-caja/wiki/SES

Re: Proposal: Abstract References

On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com wrote: On 10/22/2014 07:45 AM, Mark S. Miller wrote: * Only objects that have been used as keys in FastWeakMaps would ever have their [[Shadow]] set, so this could also be allocated on demand, given only a bit saying whether it

Re: Proposal: Abstract References

Please do nitpick. I wrote this in too much of a hurry and it is something that needs care. In any case, yes, transientKey. On Wed, Oct 22, 2014 at 2:46 PM, Rick Waldron waldron.r...@gmail.com wrote: On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller erig...@gmail.com wrote: On Wed, Oct 22

Re: what makes a file a module?

I agree that we should come to consensus on a file extension. The argument that it is out of our jurisdiction only makes sense to me if it is in some other group's jurisdiction. AFAICT, it is not. And consensus is needed, so let's proceed. Suggestions? Is there any reason we should still limit

Re: Throwing errors on mutating immutable bindings

On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com wrote: On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote: The static error is problematic. I'm pretty sure that engines that do lazy parsing of functions is not going to report static errors before

Re: Array.prototype.contains solutions

On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich bren...@mozilla.org wrote: The most painful use case is the existence of perfectly reasonable ES5 code like: function Point(x, y) { this.x = x; this.y = y; } Point.prototype.toString() { return `${x},${y}`; }; You mean

Re: Throwing errors on mutating immutable bindings

On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote: Good point. If we can require all such assignments to be rejected statically, why is a runtime assignment to a const variable even possible? Can't we just assert

Re: Maximally minimal stack trace standardization

Yes, I believe that we should consider some non-strict non-sloppy functions, such as .bind()ings of strict functions, to also normatively have some TCO/PTC requirements. However, it is too late to consider such for ES6 and we can always extend such TCO/PTC requirements to more cases later. On

Re: ... A community is writing the spec...

Meant this message is so uninformed that On Sep 10, 2014 6:55 AM, Mark S. Miller erig...@google.com wrote: Hi L2L, this message is uninformed that I must ask you to move to another forum, until you learn a lot more about js and web programming. This is not the place. On Sep 10, 2014 6:47

Re: use strict VS setTimeout

On Mon, Sep 8, 2014 at 7:25 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Apologies, now I see what you meant and I think option 2 would be probably ideal. I disagree. I think option #2 is rather horrible. Strictness can't be tested in JS user code, and shouldn't be. And sloppy

Re: use strict VS setTimeout

On Sun, Sep 7, 2014 at 10:29 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I know this is probably W3C land but the following code shows the global object in every JS engine I could test: ```js (function () { 'use strict'; setTimeout(function () { 'use strict';

Re: use strict VS setTimeout

On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Yes Axel, that's how it works, this will show undefined indeed all over ```js (function () { 'use strict'; function g() { console.log(this); } g(); // undefined setTimeout(function () {

Re: use strict VS setTimeout

On Sun, Sep 7, 2014 at 11:27 AM, Domenic Denicola dome...@domenicdenicola.com wrote: I don't understand why this is any more surprising than any other function that calls its callback with .call(something). The issue is what the something should be, and which choices for something are

Re: use strict VS setTimeout

On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/7/14, Domenic Denicola dome...@domenicdenicola.com wrote: I don't understand why this is any more surprising than any other function that calls its callback with .call(something). It doesn't matter whether

Re: use strict VS setTimeout

On Sun, Sep 7, 2014 at 12:50 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/7/14, Andrea Giammarchi andrea.giammar...@gmail.com wrote: this is getting nowhere ... yeah Garret, you can use `.call` and we all know that ... Now I want you to answer this: why on earth would you expect

Re: Duplicate property names (was Re: @@new)

Regarding Domenic's question: Domenic Denicola wrote: Another way of guiding the decision: I don't quite recall where the spec landed `{ x: 1, [x]: 2 }`, but we should probably be consistent with that. The initial value of the x property would be 2. It should not be observable that it was

Re: Standard builtins' prototypes and toString

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 experiment Nightly tries first with a positive outcome, I expect that's what we'll

Re: Standard builtins' prototypes and toString

On Thu, Jun 12, 2014 at 8:19 AM, 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,

Re: Integrating the Webs' dependency systems

On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/29/14, 11:12 AM, Mark S. Miller wrote: But if the issue is of general interest across many hosting environments, then it should probably be handled by JS and TC39, rather than duplicating work among the hosting

Re: Integrating the Webs' dependency systems

Parallel experiments would be great. On Thu, May 29, 2014 at 8:59 AM, Kevin Smith zenpars...@gmail.com wrote: Assuming the requirements of the different hosting environments are similar enough that it's possible to factor out some sort of common thing (presumably with hookable bits for the

Re: Object.getOwnPropertyDescriptor can return just about anything

This is a stop-the-train scale disaster. ES6 cannot ship in this state. We need to fix this asap. My apologies for not tracking this issue better earlier. I thought we had all agreed on the constraints, so I did not pay sufficient attention to what I thought was merely the ironing out of minor

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 9:11 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: 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 concavel...@gmail.com wrote: Interesting sourcemap usage. But is there any hope for

Re: standardizing Error.stack or equivalent

On Thu, Mar 27, 2014 at 1:37 PM, Mark S. Miller erig...@google.com wrote: Is this extended format documented anywhere? On Thu, Mar 27, 2014 at 10:36 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Thu, Mar 27, 2014 at 12:31 PM, Mark Miller erig...@gmail.com wrote

Re: standardizing Error.stack or equivalent

I wasn't aware that v8 does that. Is this format documented anywhere? On Thu, Mar 27, 2014 at 2:23 PM, Christian Plesner Hansen c...@p5r.orgwrote: js try { eval(eval('FAIL')); } catch (x) { print(x.stack); } @typein line 2 eval line 1 eval:1:1 @typein line 2 eval:1:1

Re: Multiline Strings

On Sat, Mar 8, 2014 at 11:05 AM, Mark S. Miller erig...@google.com wrote: On Sat, Mar 8, 2014 at 9:30 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Mar 8, 2014 at 6:10 PM, John Barton johnjbar...@google.comwrote: You may like to take a look at how the traceur compiler (

Re: Multiline Strings

On Sat, Mar 8, 2014 at 11:14 AM, Mark Miller erig...@gmail.com wrote: [...] To see these for yourself in your own browsers, visit http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html . and click of the last two [+]s to expand these. -- Cheers, --MarkM

Re: eval of let, etc. Was: Re: restrictions on let declarations

No, absolutely not. By lexical, I took Allen to mean the new reliably block-local binding forms: let, const, class On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb

Re: Rename Number.prototype.clz to Math.clz

On Thu, Jan 16, 2014 at 12:09 PM, Joshua Bell jsb...@google.com wrote: On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.comwrote: On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff jason.orendo...@gmail.com wrote: At the risk of putting too many nails in the board... The

Re: Rename Number.prototype.clz to Math.clz

On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote: On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com wrote: At the risk of putting too many nails in the board... The rationale seems to propose that (0).clz() === 32, but the hypothetical

Re: Additional Set.prototype methods

https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables On Tue, Dec 31, 2013 at 5:06 PM, Forrest L Norvell forr...@newrelic.comwrote: On Tue, Dec 31, 2013 at 2:45 PM, Mark S. Miller erig...@google.comwrote: Sets and Maps are deterministically ordered by insertion order. I

  1   2   >