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 w
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,
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 the
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
>>
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 tr
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 the
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
>
> O
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 is
> 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. I
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
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.
https://
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 n
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
attitude
quot;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 wrote:
> Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript
> spec is correct.
>
> 2**53 is i
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 <
anders.rundgren..
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
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
> important part in tha
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:
> I put together a short
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 functions to sets be us
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
> configured to restri
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 + break)?
>
> ```js
> pr
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
>
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 direct
> eval) already put
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"
(SAB
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 perfor
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
bo
On Fri, Aug 4, 2017 at 3:18 PM, Alex Vincent wrote:
> In particular, for many permanently absent traps, the proxy can just pass
>> these through directly to the target without much analysis.
>>
>
> Your suggested changes to the ECMAScript specifications seem to focus on
> permanently absent traps
The benefit that I care about more:
"The following regularity holds between A and B except for this tiny edge
case."
is a much greater cognitive burden on everyone, forever, than
"The following regularity holds between A and B."
On Wed, Jul 19, 2017 at 10:09 AM, Mike Samuel wrote:
> On Wed,
Hi Allen, that one word change would correct the inconsistency. I agree
that it is the most that is likely to happen. I would prefer that we
actually fix JS so that it is a superset of JSON, as I preferred during our
es3.1 days. However, I agree that this is
a) even less likely to happen now th
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 clear, did I? On a non-error in the g
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 definition, is not a good
ide
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
> wrote:
>
>>
>> > Le 26 mai 2016 à 10:43, G. Kay Lee <
>>
uot; 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 wrote:
> > On Mon, Apr 11, 2016 at 9:31 P
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 tick.
>
> And yes, engine
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 span, I put only one pair
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 issue, functionProxy.toString()
> will work r
Only because typeof f === 'function' divides the world into callables and
non callables.
On Oct 26, 2015 3:20 PM, "Allen Wirfs-Brock" wrote:
>
>
> > On Oct 26, 2015, at 11:20 AM, Mark Miller wrote:
> >
> > I like the idea a function proxy is mor
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 "function
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 error?
>
> Possible val
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 in general. But we made a few exceptions, esp
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 the
+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 wrote:
> RFC 7464 has a different format (0x1E at beginning of every record) and a
> different media type
On Mon, Jul 13, 2015 at 6:53 PM, Isiah Meadows 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 proposal
> here is, I f
For the record, there are no so-called private symbols. The concept being
referred to here is an implementation-only concept for naming an internal
property. These naming-things are never reified and available to JS code
and must not be.
On Thu, Jul 2, 2015 at 1:22 AM, Andreas Rossberg
wrote:
>
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 o
Perhaps. I encourage you to draft a possible concrete proposal.
On Sat, Jun 13, 2015 at 11:30 AM, Jordan Harband 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] =
> Object.fre
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
wrote:
> I don't agree that @@species is useful at a
On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison 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
> on logic in the
On Wed, Jun 10, 2015 at 7:37 AM, Allen Wirfs-Brock
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
> wrote:
>
>> Do you ever test that the object returned by `Promise#timeout(n)` is
>> something other than a plain promise?
>>
>
>
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 invol
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
https://mail.mozill
If the prop property accessed by super.prop is an accessor, super.prop = x;
should invoke its setter. super.prop should invoke its getter.
On Tue, Apr 21, 2015 at 4:18 AM, Allen Wirfs-Brock
wrote:
>
> On Apr 20, 2015, at 12:39 PM, Jason Orendorff wrote:
>
> On Mon, Apr 20, 2015 at 12:44 PM, Alle
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
wrote:
>
> On Apr 20, 2015, at 5:28 PM, Caitlin Pot
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
im
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, Andr
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
wrot
On Wed, Mar 11, 2015 at 6:31 PM, John Lenz wrote:
> I'll retract that suggestion having tried to write an argument for it.
>
Thanks.
> It sad though, removing "stack" isn't really an option.
>
a) It has never been "added", in the sense that it does not appear in the
std.
b) It differs so
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 o
On Mon, Mar 2, 2015 at 10:45 AM, Allen Wirfs-Brock
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 by some metad
On Mon, Mar 2, 2015 at 10:25 AM, Dean Tribble wrote:
> On Mon, Mar 2, 2015 at 6:32 AM, Gray Zhang wrote:
>
>> +1 to the ignore term, I’ve opened an issue about it in
>> https://github.com/promises-aplus/cancellation-spec/issues/14
>>
> I have little attachment to any term, but there's value in k
On Mon, 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 by some metadata that indicated whether the result of the
> function would
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
non-ar
On Feb 26, 2015 5:04 PM, "Allen Wirfs-Brock" wrote:
>
...[arrow functions]...
>
> If we went that route I'd probably still stick with 'function.next' for
that use case
Since we don't have arrow generator functions...
> Allen
>
> ___
> es-discuss mailin
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 wrote:
> From: Mark Miller [mailt
earch?q=ImplicitThis+site%3Awhatwg.org&ie=utf-8&oe=utf-8#q=%2BImplicitThis+site:whatwg.org
>
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Domenic Denicola
> Sent: Sunday, February 22, 2015 16:39
> To: Mark Miller
>
On Sun, Feb 22, 2015 at 1:03 PM, Domenic Denicola 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
>
>
> addEventListener("foo", function () { });
>
>
> Is this
On Thu, Feb 19, 2015 at 12:14 PM, Axel Rauschmayer 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
Put better, the spec requires that Object.freeze(Object.prototype) works.
On Sat, Jan 24, 2015 at 2:57 PM, Mark Miller wrote:
>
>
> On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows
> wrote:
>
>> > From: "Mark S. Miller"
>> > To: Gary Guo
>> &
On Sat, Jan 24, 2015 at 2:42 PM, Isiah Meadows wrote:
> > From: "Mark S. Miller"
> > To: Gary Guo
> > Cc: "es-discuss@mozilla.org"
> > Date: Sat, 24 Jan 2015 07:11:35 -0800
> > Subject: Re: @@toStringTag spoofing for null and undefined
> > Of course it can, by tamper proofing (essentially, fre
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 late
JavaScript X === EcmaScript Y :- X === Y + 2009 && Y >= 6;
On Thu, Jan 22, 2015 at 4:17 PM, Brendan Eich 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 be "bad
it seems like a risky
> move to unlock it now.
>
> On Wed, Jan 21, 2015 at 1:00 PM, Mark S. Miller
> wrote:
>
>> On Wed, Jan 21, 2015 at 12:57 PM, Mark Miller wrote:
>> [...]
>>
>>> Is there anyone who wouldn't be happy with "all
>>>
On Wed, Jan 21, 2015 at 12:51 PM, Jordan Harband 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 not be configu
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,
On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky wrote:
> On 12/4/14, 4:45 PM, Mark Miller wrote:
>>
>> On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky wrote:
>>>
>>> Sure, for a scope chain. Testcase at
>>>
>>> https://web.mit.edu/bzbar
On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky 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 al
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 wrote:
> Le 02/12/2014 14:24, David Bruant a écrit :
>>
>> Hi,
>>
>> I feel like I've been in an equivalent discussion som
On Sun, Nov 30, 2014 at 6:12 PM, Mark S. Miller 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 whose target i
On Sun, Nov 23, 2014 at 8:22 AM, Mark S. Miller 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
> www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf
>
>
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
wrote:
>
>
> On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller wrote:
>
>>
>>
>> On Wed, Oct 2
On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink 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 is pres
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 o
On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg
wrote:
> On 1 October 2014 16:09, Erik Arvidsson 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 doing a
> > full parse of the function.
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock
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 that this cannot
On Wed, Oct 1, 2014 at 12:21 AM, Brendan Eich 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
>
> Poin
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 Mon,
Meant "this message is so uninformed that...".
On Sep 10, 2014 6:55 AM, "Mark S. Miller" 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 AM, "L2L 2L
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 slopp
On Sun, Sep 7, 2014 at 12:50 PM, Garrett Smith
wrote:
> On 9/7/14, Andrea Giammarchi 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 a global
> > context in a setTimeout or s
On Sun, Sep 7, 2014 at 11:44 AM, Garrett Smith
wrote:
> On 9/7/14, Domenic Denicola 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
> the
> > callback is strict or not; .call(wind
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 s
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(fun
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'
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
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 d
On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock
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(Date.prototype)` w
On Thu, May 29, 2014 at 9:50 AM, Ian Hickson wrote:
[...]
> This suggests that the plan should be to instead make sure that whatever
> ES6 defines can be used by other specs to define the Web's loading model.
> Is extending the ES6 model (not the API, but the underlying model with
> load records
Parallel experiments would be great.
On Thu, May 29, 2014 at 8:59 AM, Kevin Smith 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 parts where
On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky 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 environment
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 kin
1 - 100 of 214 matches
Mail list logo
