Re: Standard builtins' prototypes and toString
Allen Wirfs-Brock wrote: The spec. current says throw for this Symbol.prototype case. The (reasonable) opposing view is that toString should never throw. Other than the protoype-is-not-an-instance it all about unlikely edge cases where toString methods are applied to the wrong kind of object. js Object.create(null).toString() typein:1:0 TypeError: Object.create(...).toString is not a function It happens. Better to catch that error (Symbol.prototype flowing into an implicit conversion) early? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standard builtins' prototypes and toString
Allen Wirfs-Brock wrote: [ object ???] [object WTF] :-P /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
So far, I prefer your proposal to draft ES6 by a lot -- especially since I missed the hideous Number special-casing spread around in the draft! Jason Orendorff wrote: Is `C === C[@@new]`? Good question. I think calling `C(...args)` should be the same as calling `new C(...args)`. How best to specify that, I'm not sure. Isn't the question of whether C(...args) is allowed as short for new C(...args) a separable option from the rest of your proposal (and from draft ES6)? I'd hate for your proposal to founder on this somewhat controversial issue. I don't think `C === C[@@new]` needs to be a goal, Should be specified not to be === in my view because: it wouldn't hold for regular functions, or for classes that don't define a constructor (those inherit their @@new method from the base class), or for classes that contain a `static [Symbol.new]()` method. See Allen's latest followup on this -- is it a static error to have both constructor and the static [Symbol.new]() method? But as an implementation detail, if that's the easiest way to specify it, OK. See above. LMK if you disagree with anything, or anything's unclear. Thanks again for writing up your counter-proposal! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
See Allen's latest followup on this -- is it a static error to have both
constructor and the static [Symbol.new]() method?
IMO it shouldn't be, because it'd be weird to get an error for `constructor` + `static
[Symbol.new]()`, but to not get an error for `constructor` + `static [Symbol[n +
ew]]()` and similar.
Silly me -- strike that static before error -- it still could be a
strict error, but see latest meeting minutes where MarkM changed his
position (cited below).
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.
*Mark Miller:* I am ok with removing the constraint that duplicate
dynamic object properties throw (in strict mode) with the caveat that we
also remove the same constraint for duplicate static properties.
from
http://esdiscuss.org/notes/2014-06-06#rest-properties-and-spread-properties-sebastian-markb-ge-.
Still, in this case we have a ClassElement special form,
constructor(){}. This distinction adds a choice not present in the
ObjectLiteral case: to have a strict (dynamic) error on duplicate
Symbol.new-equivalent name.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
Boris Zbarsky wrote: If we _can_ have a world in which web platform objects don't exist in constructed-but-not-initialized states, I personally would much prefer that +¶ /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@new
Kevin Smith wrote: Sorry for my previous gut reaction. This looks like a good proposal, but it makes a break with the evolutionary design of ES classes. How so? @@create or @@new, either way something in ES6 is new that was not in classes-desugared-to-functions. Furthermore, when we were hashing out classes, several people (including me I think) tried to suggest ways to maintain the `C() = new C()` equivalence established by the built-ins, and it never really took off. I think maybe the reason is that that equivalence isn't very useful. I think Jason's proposal leaves this C C[Symbol.new] condition a separate choice from everything else, and choosing the way you prefer does not break the rest of the design. Jason? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: .entries() vs. the web
Would .items fare better, I wonder. /be Oliver Hunt wrote: It turns out there are a number of sites (such as mobile.twitter.com http://mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided. We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful pretend that you're undefined horror. --Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
Andrea Giammarchi wrote:
In such case the only concern would be why `Object.prototype` is
considered but not inherited properties too.
Because NoSuchProperty is meant to be inserted just before
Object.prototype, avoiding that loop.
What's more, the loop is unnecessary:
var NoSuchProperty = Proxy({}, {
get: function(target, name, receiver) {
while (target = Object.getPrototypeOf(target)) {
if (name in target) {
return Reflect.get(target, name, receiver);
}
}
throw new TypeError(name + is not a defined property);
}
});
If NoSuchProperty is inserted just before Object.prototype on a chain of
ordinary objects, its get handler won't be invoked until no such
property is indeed found along the path from the original target to
NoSuchProperty. Therefore all iterations but the last (where target is
Object.prototype) are redundant.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Null iterable in for-of?
Jeff Walden wrote: On 06/12/2014 03:05 PM, Allen Wirfs-Brock wrote: I believe this behavior for for-in was added in ES5. My recollection was that Doug Crockford pushed for it. I don't recall if it was because it matched web reality or simply because he thought it was a good idea. It was added for web compatibility, to track what was originally a SpiderMonkey implementation bug, I believe. Actually, if memory serves, IE JScript tolerated null and undefined on right of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone with the jwz nostalgia Netscape 2/3 browsers, please test. I don't think bug-hiding precedent trumps bug-finding, personally. Allen? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Value types versus .valueOf
Alex Vincent wrote: var x = new SmallDecimal(2); var y = new SmallDecimal(3); [x y, x y, x == y, x = y, x = y, x != y] valueOf doesn't work for SmallDecimal(2) == SmallDecimal(2), though. You have to hash-cons, which kils performance. String relational order is wrong for numeric types, to boot: js '10' '2' true So valueOf is a no-go. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A reprieve for ES6 comprehensions
Tab Atkins Jr. wrote: On Fri, Jun 6, 2014 at 1:57 PM, Andy Wingowi...@igalia.com wrote: 1: Essential differences == Array comprehensions are eager. Generator comprehensions are lazy. Array comprehensions desugar into a do expression à la ES7. Generator comprehensions desugar into an IIGFE (immediately-invoked generator function expression) -- sorta, anyway. (Generator function desugaring is not exact due to arguments/this/etc scoping and properties on the generator function.) This is an essential difference in the use of the iterator, and so it makes sense to distinguish these at the source level as well. I'm not sure I understand. Is this an argument against Python's use of similar syntaxes as well? That is, do you also disagree with Python's high similarity between array comprehensions and generator comprehensions? No, the problem is there's no way to do a generator comprehension in (what we saw of) the new syntax. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
Nicholas C. Zakas wrote:
It can be done with Proxy, but that kind of sucks because I always
need to go through the extra step of creating the Proxy for each
object and passing around the Proxy instead. To me, this is similar to
setting a property to be readonly in strict mode, except its writeonly
(or rather, write-first).
What about the code I showed, which shows a singleton being spliced high
on many objects' prototype chains to handle the missing property throw?
js var NoSuchProperty = Proxy({}, {
has: function(target, name) { return true; },
get: function(target, name, receiver) {
if (name in Object.prototype) {
return Reflect.get(Object.prototype, name, receiver);
}
throw new TypeError(name + is not a defined property);
}
});
js var obj = Object.create(NoSuchProperty)
js obj.foo = 42
42
js obj.foo
42
js obj.bar
/tmp/p.js:7:4 TypeError: bar is not a defined property
You could avoid Object.create by assigning to a Constructor.prototype,
or hacking with __proto__, of course.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
Just FTR, I'll put a ratioanlized ES7 proposal on the agenda for the
July TC39 meeting, as per
https://twitter.com/BrendanEich/status/475067783282057216
Thanks to Nicholas for the suggestion!
/be
Brendan Eich wrote:
Nicholas C. Zakas wrote:
It can be done with Proxy, but that kind of sucks because I always
need to go through the extra step of creating the Proxy for each
object and passing around the Proxy instead. To me, this is similar
to setting a property to be readonly in strict mode, except its
writeonly (or rather, write-first).
What about the code I showed, which shows a singleton being spliced
high on many objects' prototype chains to handle the missing property
throw?
js var NoSuchProperty = Proxy({}, {
has: function(target, name) { return true; },
get: function(target, name, receiver) {
if (name in Object.prototype) {
return Reflect.get(Object.prototype, name, receiver);
}
throw new TypeError(name + is not a defined property);
}
});
js var obj = Object.create(NoSuchProperty)
js obj.foo = 42
42
js obj.foo
42
js obj.bar
/tmp/p.js:7:4 TypeError: bar is not a defined property
You could avoid Object.create by assigning to a Constructor.prototype,
or hacking with __proto__, of course.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: for-loops and declaration-like init expressions
Allen Wirfs-Brock wrote: Over and beyond the breaking change WRT function, I bet a tasty donut that we cannot make this breaking change, so why should we fool around with anything similar for class? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to
throw an error if you try to read from a property that doesn't
exist (instead of returning `undefine`).
This can be achieved with Proxy right, or is that too cumbersome?
js var NoSuchProperty = Proxy({}, {
has: function(target, name) { return true; },
get: function(target, name, receiver) {
if (name in Object.prototype) {
return Object.prototype[name];
}
throw new TypeError(name + is not a defined property);
}
});
js var obj = Object.create(NoSuchProperty)
js obj.foo = 42
42
js obj.foo
42
js obj.bar
/tmp/p.js:7:4 TypeError: bar is not a defined property
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
LOL - as if O.p has getters!
Thanks, this is more general in case of insanity.
/be
On Jun 5, 2014, at 6:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 5, 2014, at 5:52 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to throw
an error if you try to read from a property that doesn't exist (instead of
returning `undefine`).
This can be achieved with Proxy right, or is that too cumbersome?
js var NoSuchProperty = Proxy({}, {
has: function(target, name) { return true; },
get: function(target, name, receiver) {
if (name in Object.prototype) {
return Object.prototype[name];
}
throw new TypeError(name + is not a defined property);
}
need to make sure accessor methods use the right this value:
get: function (target, name, receiver) {
if (name in Object.prototype) return Reflect.get(Object.prototype,
name, receiver);
throw new TypeError(name + “ is not a defined property”);
}
});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations
Andreas Rossberg wrote: On 4 June 2014 00:12, John Lenzconcavel...@gmail.com wrote: No I intentionally used let. This is not legacy code (I shouldn't have use the word existing) but new sloppy mode code that would like the code to be block scoped. Why would you want to write new sloppy mode code, though? Honest question. Realistically, you should consider the larger question, why will new sloppy-mode code be written? The answer is obvious: it's the default mode. But there's still a fair amount of hostility to use strict, based on folklore about deoptimization (one reason), but also based on other arguments. One that came up on twitter recently: https://twitter.com/rem/status/471766603034791936 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Safari 8 ES6-ish implementation.
Just FYI, Kangax's table now includes echo-js which is doing great! http://kangax.github.io/compat-table/es6/ /be Oliver Hunt wrote: All these bugs can be filed at bugs.webkit.org http://bugs.webkit.org (which is a much better place than a mailing list), anyway: On Jun 4, 2014, at 1:08 PM, C. Scott Ananian ecmascr...@cscott.net mailto:ecmascr...@cscott.net wrote: So... Safari 8's betas were just released. It contains a partial ES6 implementation -- but one which fails many of `es6-shim`s test cases. See https://github.com/paulmillr/es6-shim/issues/252#issuecomment-45141791 Is anyone on es6-discuss in contact with the Safari team? Can we get Safari 8 made spec-compliant before release, so that es6-shim doesn't have to shim around a broken implementation? In particular: * `ArrayIterator` is exposed as a global https://bugs.webkit.org/show_bug.cgi?id=133494 * `Array#find` and `Array#findIndex` don't work right on sparse arrays or array-like objects Fixed in trunk File bugs on anything you encounter - we can’t fix bugs if we don’t know that they’re there. —Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Dmitry Soshnikov wrote: On Sat, May 31, 2014 at 1:41 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Matthew Robb wrote: Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned. Right, and they are in scope no matter what. Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss? No, seems it's the only problem. Also, just to add: esprima parser also has this bug yet (can't have param default value with patterns). Nicholas kindly filed https://bugzilla.mozilla.org/show_bug.cgi?id=1018628 to track the SpiderMonkey bug. If you file an Esprima one, could you cite it to the list? Thanks, /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Nicholas C. Zakas wrote:
```
function setCookie(name, value, { secure, path, domain, expires } = {}) {
console.log(secure);
// ...
}
```
Unfortunately, that resulted in a syntax error in Firefox.
Could you please file a bug against SpiderMonkey? Thanks,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Matthew Robb wrote: Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned. Right, and they are in scope no matter what. Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RFE: Allow newline when returning an anonymous object
Oliver Hunt wrote:
What you're asking for is grammatically ambiguous in a way that would
potentially break existing content, and (generally) leads to really
interesting parsing behaviour.
As Doug Crockford has argued, this is why KR style is better in JS:
always put the { at the end of the line whose first token starts the
statement.
if (C) {
. . .
}
and not
if (C)
{
. . .
}
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RFE: Allow newline when returning an anonymous object
Oliver Hunt wrote: That's an unfortunate side-effect. I think that developers should be able to pick their own code styles. After all, most of these choices are subjective. Anyway, thanks for the head's up. They can choose their own style, just not their own syntax. Right, and syntax can restrict style (consider Python). A bunch of us old timers have come around to the idea that languages should dictate style harder, to avoid pointless style wars and attendant patching woes. Even without too much restrictiveness, languages lately tend to grow tools to enforce canonical style (e.g., gofmt). KR style for JS is best. I'm an old C hacker. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntactic sugar for using a function as if it were a method of its first argument
Jasper St. Pierre wrote: I'm not sure I like it. Given how other languages use the :: operator, I'd expect Foo::bar to do some sort of static property lookup for a name called bar on Foo, not bind the local variable Foo to the local variable bar. That's not what the proposed bind operator does. I think bar.bind(Foo) is more than enough. That allocates a new (and subtly different) bound function object. Part of the motivation for the bind operator is to avoid the allocation (and the subtle difference, secondarily). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The Existential Operator
C. Scott Ananian wrote: I've written a lot of coffeescript code and the existential operator is indeed one of the joys of the language. I like David's You mean Claude's? /be attempt to bring rigor and compositionality to it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The Existential Operator
Claude Pache wrote: Le 23 mai 2014 à 03:04, Brendan Eichbren...@mozilla.org a écrit : C. Scott Ananian wrote: I've written a lot of coffeescript code and the existential operator is indeed one of the joys of the language. I like David's You mean Claude's? /be I must confess to have asked myself the same question at first reading :-p But see the message of Axel posted a few hours ago in this thread. Where Axel wrote David seems to suggest a compositional version: `o?.p?.q?.r` I see a different problem: so heavyweight that many people will say it isn't worth the cost of standardizing, and what about the `?(` form in CoffeeScript? /be —Claude attempt to bring rigor and compositionality to it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The Existential Operator
Dmitry Soshnikov wrote:
Will the Existential Operator for properly accessors be something
interesting to consider for ES7 spec? Currently CoffeeScript uses it well.
Please see
http://esdiscuss.org/topic/sept-18-tc39-meeting-notes#content-2
and find ARB: This is non-compositional. Citing text for reader
convenience:
Existential Operator (strawman discussion)
(Presented by Brendan Eich, Mozilla)
Significant desire include a null and undefined check in syntax/operator
form (a la coffeescipt)
| o = {}
r = o?.p.q.r
r = o?.p?.q.r
|
Mixed discussion about the needs and use cases as they apply to
coffeescript code.
ARB: This is non-compositional
| o = {}
r = o?.p.q.r
r = (o?.p).q.r
r = o?.p.q.r()
|
Results in…
| var o, r;
o = {};
r = o != null ? o.p.q.r : void 0;
r = (o != null ? o.p : void 0).q.r;
r = o != null ? o.p.q.r() : void 0;
|
Non-starter.
DH: Why not an operator that needs to be explicit?
| o?.p?.q?.r
|
LH: Why would you ever even use it on the first?
BE: Forget all of the problems with coffeescript's impl, the need exists.
YK: In the common cases, where it works, it works well. Where it
doesn't, it falls apart unexpectedly.
WH: What about other contexts such as p?[x], p?.q[x], and p?(x) ? [Note
that grammar problems arise for some of those.]
General agreement.
*Conclusion/Resolution* Seems useful, but not now. Semantics are unclear
---
The notes ended a bit too optimistically in my view! Non-starter.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Error Instances Stack Property
Garrett Smith wrote: Should Error Instance have a standard `stack` property? Seems to be a very common feature nowadays. Why isn't it being specified in EcmaScript 6? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack Thanks, Lots of searchable stuff: http://wiki.ecmascript.org/doku.php?id=strawman:error_stack http://esdiscuss.org/topic/standardizing-error-stack-or-equivalent http://esdiscuss.org/topic/formalize-error-stack http://esdiscuss.org/topic/error-stack and more, easily discovered via site:... searches. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
I take a more expansive view, because of evolution. JS and languages that currently target it, and also languages that might in the future target it, are co-evolving. They influence one another. JS is growing SIMD and other lower-level APIs (perhaps even ARB_compute_shader in a future WebGL iteration). Value objects for more numeric types are coming. Also, the Harmony era has JS as better target for compilers as an explicit goal. So it seems to me worthwhile to talk about certain multi-language VM design issues. Bytecode in general, perhaps a standard, fast, zero-verification AST codec format, seems fair game for es-discuss. But I agree that putting the bytecode syntax cart ahead of the horses (language designs and their semantic requirements) is a mistake. As McCarthy suggested, there may be several concrete syntaxes. What's the abstract syntax, and ahead of that, what does it mean? /be Florian Bösch wrote: Well, it is a thread on bytecode, that had a discussion on bytecode, but sure, whatever. On Mon, May 19, 2014 at 4:07 PM, Till Schneidereit t...@tillschneidereit.net mailto:t...@tillschneidereit.net wrote: On Mon, May 19, 2014 at 3:55 PM, Florian Bösch pya...@gmail.com mailto: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 to say, but then that's a pretty useless discussion entirely. No, I don't want to talk about a bytecode format *at all*. At least not on this list, as this list is about ECMAScript, and nothing else. If you want to make the case for a bytecode format for the web, take it to some other forum. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
Axel Rauschmayer wrote: What is the best “bytecode isn’t everything” article that exists? The “the web needs bytecode” meme comes up incredibly often, I’d like to have something good to point to, as an answer. This one looks good: http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html That's a good one. It reflects lots of discussions Alon and others, including yours truly, have had over the years. The important point is not just bytecode isn't everything -- also important are trade-offs in have two syntaxes, something that came up here on es-discuss long ago. Here's a post from Maciej of Apple: https://mail.mozilla.org/pipermail/es-discuss/2009-December/010238.html The topic then was AST encoding, not something people think of as bytecode. Michael Franz at UCI and Ben Livshits at MSR had worked on arithmetic coding of ASTs (avoids need for verification). The topic is deep and memes die hard. I think Alon's post is the right thought-piece; anyone have others? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native base64 utility methods
Mathias Bynens wrote:
(but it requires `ArrayBuffer` / `Uint8Array`).
In ES6, so no problem proposing Text{En,De}coder for ES7.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Perhaps @@unscopable shouldn't be a Set...
Including Tom because proxies and MOP. /be Erik Arvidsson wrote: This was never resolved and the spec is incomplete here On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: So here is another concern, about the scheme we agreed to last week. It needs to match a found own property against the possibility of an own @@unscopable property on the same object and that object may be somewhere up the inheritance chain of the actual with object. The means that [[HasProperty]]/[[Get]]/[[Set]] can not be used to do those resolve binding in an ObjectEnvironmentRecord because they don't tell us where the property was found. Instead, ObjectEnvironmentRecord needs to reimplement its own property lookup using [[GetOwnProperty]] and [[GetInheritanceOf]]. However, if the with object is a proxy that means we may be bypassing the actual inheritance mechanism implemented by the Proxy's 'has'/'get'/'set' traps and that could introduce observable semantics irregularities. Specifying the duplicated lookup is doable but a pain. That and the semantic issues WRT proxies makes me a lot less comfortable with the added complexity of supporting @@unscopable. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft Rev24 now available
Want to mention https://github.com/jlongster/es6-macros while this thread is still live. /be Kevin Smith wrote: https://github.com/zenparsing/esparse The actual transpiler is at https://github.com/zenparsing/es6now. I really need to add some documentation, but you can play with classes, arrows, and other things in the REPL. If you have Node 0.11+, you can also try async functions (yay). Traceur is a much more complete transpiler, though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterators, generators, finally, and scarce resources (Was: April 10 2014 Meeting Notes)
Domenic Denicola wrote:
Dave and Andy's responses have me pinging back and forth as to which side I'm
on.
Are you off the fence yet? I can't tell :-P.
But inconvenience is easily solved via MOAR SUGAR:
```js
for (var line using files) {
if (line == '-- mark --') {
break;
}
}
```
No, that's syntactic salt. It will be forgotten when needed. It mixes
with sugar (for-of) to leave a bad taste. It bloats surface syntax.
The reason to revive close as return is convenience. It's a good reason
when fully rationalized. Yes, scenario solving and uncompositional
primitives are bad in general. But as Dave argues, the specific case
survives by the full rationale given.
I'd rather give the ecosystem another year or so without a standard dispose
protocol, if it means we avoid making changes to ES6 this late in the game.
That's not a good argument, compared to the now-or-never one Mark made.
Indeed with rapid release, penalizing convenience and waiting for
ecosystem effects can make overcomplicated, convenient, and just bad
total designs out of piecewise steps that you might like because they
avoid committing to convenience :-P.
Design is an art still (Knuth: we can't teach a computer to do it).
Robo-processes and ecosystem robots from the future do not replace it.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Iterators, generators, finally, and scarce resources (Was: April 10 2014 Meeting Notes)
Brendan Eich wrote: Indeed with rapid release, penalizing convenience and waiting for ecosystem effects can make overcomplicated, convenient inconvenient , and just bad total designs out of piecewise steps that you might like because they avoid committing to convenience :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Mark S. Miller wrote: BTW, return() should be idempotent. Is it? Since .return takes an argument whose value is observable, I think not. Hmmm. This is interestingly similar to multiple calls to resolve. Yes, and note that Python's generator.close (no return value parameter, recall it throws a built-in exception, GeneratorExit, at the generator iterator) is idempotent. Calling it on a closed generator is a no-op. This may be important for optimizability. Allen's speculation is that JITs can sort out early from done loop termination paths and maybe-call return only in the early cases, but I'm not so sure. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Kevin Smith wrote: In this case we have try-finally statements as an existing feature. The semantics of this feature is a bounded execution scope with a cleanup action on completion. This feature is widely used and has always been internally consistent and reliable, expect for catastrophic external failure or intervention (ie, externally imposed process termination, power failure, etc). People use it for all sorts of things, including bounded resource management. Zeroing in on cleanup action on completion: don't co-routines by nature prohibit us from reasoning in this way about completion? It seems to me that this shift is broader than just `try/finally`, although I agree that `try/finally` shows some particularly acute symptoms. And I also agree that we should not provide gratuitous footguns. Unfortunately, though, I'm having a hard time forming an opinion on how disallowing `try/yield/finally` would balance out. We're at risk of going around the design wheel again. Python started by banning yield in try: and then added it, with GeneratorExit as a magic exception thrown from Python's implicitly-called generator.close method at a yield-in-try that would run the finally clauses. When Igor Bukanov and I were working on ES4 and prototyping it in SpiderMonkey, Igor urged forcing a return instead of throwing a magic exception. He even persuaded Philip J. Eby on python-dev that forcing return was better, possibly even for Python (which IIRC then went in the direction of reifying control effects as exceptions). Instead of kicking the can and dragging this out yet again, I'm ok with return automation as proposed. Yeah, we're doing a common-ish use-case affordance. No, it isn't the last case where scoped resource release will come up. But yes, it has precedent in other languages and it's useful. BTW Dave Herman persuaded me we don't need to use a symbol for the name; 'return' is ok if 'next' is. The iteration protocol hooks via @@iterator, which returns an instance of something coded new implementations, so implementors can avoid using 'return' for a different purpose without conflict. IOW, one symbol-name is enough! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Mark S. Miller wrote: Regarding the points: #1 yes, we cannot provide one that's reliable, so let's not claim that it is reliable. Indeed it is not safe, even excluding yield, to assume finallys run in browser contexts, unless you can prove termination of trys (which is hard, right? Halting problem and all that). #2 yes it does. I acknowledge that this is a genuine cost. I think I can make your case stronger: without |return| one cannot be sure a generator iterator |it| parked at a yield won't resume some time later. To ensure that it is really done, call it.return(). Might this be important for reasoning about security? BTW, return() should be idempotent. Is it? #3 for those rare cases where it is inappropriate, like this example, better not to use a for/of anyway to make the unusualness of this code's purpose more explicit. Definitely -- given the implicit @@iterator call from (among other places) for-of constructs, it's best with for-of loops to avoid any reuse of the iterator later. Such hinky multi-loop consumption of a single iterator should be considered bad style. One can still do it, of course. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Allen Wirfs-Brock wrote: If (and it's still an open question) it make sense semantically to call return on for-of initiated generators on unwind, then that is what we should do. That's not the proposal, though, is it? Isn't the maybe-call of return for any iterator, whether a generator iterator or other object, and isn't it unconditional on whether the for-of implicitly created a fresh iterator via @@iterator? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Jason Orendorff wrote: OnThu, Apr 24, 2014 at 1:38 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: [...]What we did take seriously was the concern about not running generator finally blocks when a for-of initiated generator has an early exit. We don't need to redefine @@iterator conventions to address that issue. This reminds me --- for-of initiated here refers all the places where the spec uses IteratorStep etc., right? Things like the spread operator, destructuring assignment, and Array.from, for example? That is, we're talking about a protocol change, not a narrow change to for-of evaluation. Right? No one is talking seriously about such a change. The only proposal (let's table whether the name is 'return' or @@return) is whether for-of constructs should have a finally maybe-call of the iterator's return method, if present. Like SpiderMonkey's JS1.7-1.8 close method, based in part on Python 2.5 and up. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: April 10 2014 Meeting Notes
Sorry for the confusion -- my such a change was about changing @@iterator itself, e.g. not defining it on a generator, or trying somehow to guarantee freshness. I agree, return automation makes sense for any delimited form that implicitly calls @@iterator. There still may be an open issue, though: Python has ref-counting and pre-mortem finalization via close, last I checked. JS won't have any such thing. So are there ,in ES6, undelimited forms that implicitly call @@iterator and that won't implicitly maybe-call return? /be Jason Orendorff wrote: On Thu, Apr 24, 2014 at 2:16 PM, Brendan Eichbren...@mozilla.org wrote: The only proposal (let's table whether the name is 'return' or @@return) is whether for-of constructs should have a finally maybe-call of the iterator's return method, if present. Like SpiderMonkey's JS1.7-1.8 close method, based in part on Python 2.5 and up. But in Python, closing iterators is part of the protocol. It isn't mentioned in the language specification (Python does not have a detailed spec) but all language and library facilities that consume iterables do it, not just for loops. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: package keyword reserved?
Jonathan Bond-Caron wrote: What’s the history of the unused keyword “package”, is it from Java? In 1995, I reserved all the Java (JDK1.0 era) reserved identifiers. ES1 kept them, but ES5 cut way back, yet kept 'package' among others as reserved in strict code. No one had a championed proposal for 'package', though. It was reserved along with others because it seemed like a better idea than unreserving. Please don't rush to contrive a use for 'package' without a use-case. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: package keyword reserved?
Jonathan Bond-Caron wrote: Is it safe to use the 'package' keyword then, no proposals for using it? You mean for some other language compiled to JS to use 'package'? If so, then no: it's unsafe, explicitly so. The 'package' identifier is a strict future reserved word. Steer clear, the TC39 standards body may yet define it. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
Huzzah! /be Mike Taylor wrote: On 3/25/14, 13:23, Mike Taylor wrote: On 3/14/14, 15:53, Brendan Eich wrote: I say we should evangelize this site. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=987889 to track this. For those not following the bug, a fix for this has been committed to the battlefield.com codebase. [13:16] mekwall miketaylr: fix committed, just need to see if we can hot patch it. we just deployed a new release today and the next one is in two weeks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typed objects and value types
int64 and uint64 are integral parts of value objects, first proofs of concept even. Sorry I fell behind on the SpiderMonkey bug, I'm hoping others will take it over (cc'ed; and for V8) and revive it. It has obvious use-cases in Node.js and anything that tiles the OS syscall surface. /be Cristian Petrescu-Prahova wrote: Note that value object proposal does not address int64. FWIW, I'm too interested in solving the int64 problem somehow. The last I heard about int64 was here: http://www.slideshare.net/BrendanEich/value-objects2. How does the int64 story move forward? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Andrea Giammarchi wrote: on Android 2.3.6 (or lower) you can [try this page](http://www.3site.eu/jstests/configurable.html) which will show an alert like ``` Sorry for the initial false alarm, at least I am sure few didn't know about the getters and setters bug in actually quite recent Android 2 browsers. Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but it is incredibly out of date and not being maintained. Especially its old WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is not patched up to anywhere near current level. http://en.wikipedia.org/wiki/Android_version_history#Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Set]] and inherited readonly data properties
Mark S. Miller wrote: This mistake is my single biggest regret from the ES5 days. We had a chance to get this right when it would have been rather painless and we blew it. Indeed, as JSC and (therefore, at the time it was copying semantics) V8 did implement a fix to the override mistake. Have to let this one go, and look to the future. Although it can no longer be fixed without a lot of pain, I still think the pain of not fixing it will be greater. However, I'm sick of arguing about this one and have become resigned to using tamperProof https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#338 rather than freeze. Using tamperProof rather than freeze, your example will work. If enough others become convinced that this still can and should be fixed, we should still fix this. However, someone else would need to volunteer to champion it within TC39. Any volunteers? Wasn't there another idea, which doesn't help code that must run in old browsers, but which could help down the road? I mean the := operator as define-property not put. Didn't we defer that without prejudice? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
Marcus Stade wrote: This is assuming that the `current` or `prev` property is indeed implemented by the engine and not user land, as that indeed both carries implementation cost and the risk out running out of sync. Is there any way other than generator functions to implement iterators? Are any ol' object with a function called `next` an iterator? Any old object. It's a structural or duck-typed protocol. We won't therefore be adding complexity, which is also bad on its own. KISS wins here. More elaborate protocols for harder or let's say rarer cases are fine and not part of the mandatory minimum. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.entries(), Object.values()
C. Scott Ananian wrote: propose these for ES6/ES7? David's reply covers the main stuff, but on this question, let's be clear: ES6 is wrapped up and being edited and implemented. ES7 is fair game. Engines can implement both, so there's no reason to worry that you won't see Object.values or Object.entries for years in modern browsers. But we need to get it into consensus-ES7. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Source maps (was: Multiline Strings)
K. Gadd wrote: The accuracy of this aside, history shows that most of my users are not satisfied by 'just debug the JS, it's fairly readable'. Maybe emscripten, gwt, etc. users are more fluent in JS and don't mind debugging it, but based on what I've seen, maybe not... I do think it's important that source maps don't obscure what's happening at the JS level, though - presumably all the modern debuggers let you toggle them back off once they're loaded, so that's satisfied? I think so. Bill's point is well taken, but a tangent. The problem people face is debugging in their primary source language, mainly. Any problems with JS-level debugging are lesser and more readily solved. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 iteration over object values
Jason Orendorff wrote:
I'd like to see an Object.entries method, and Object.values for
completeness. Same visibility rules as Object.keys.
for (let [k, v] of Object.entries(myObj)) {
// do something with k and v
}
+1, or +2 counting static methods :-).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generalizable Function Modifier Syntax
Kevin Smith wrote:
async function af() {}
{ async af() { } }
This lines up with what Luke Hoban presented at the last TC39 meeting.
So far, so good (but not a done deal by any means, of course). The main
bone of contention is the use of ! in promises future-proposed syntax.
The hard part is arrow functions. One possibility would be to use
another cover grammar and place the modifier to the left of the arrow
function:
modifier [NoNewLine] Identifier =
modifier [NoNewLine] ArgumentList =
We could do this.
We could probably reuse some of the existing arrow function parsing
strategy to back up the input stream or transform the AST.
It smells, but we're used to it!
Another possibility would be to place the modifier to the right of the
argument list:
Identifier [NoNewLine] modifier = ...
ArgumentList [NoNewLine] modifier = ...
e.g.
x async= {}
(a, b, c) async= {}
This would be easier to parse, and would align with a potential
generator arrow:
x *= {}
(Presuming that we can give up on arrows with empty parameter lists.)
Bletch, and don't multiple risks unnecesasrily by entangling with
opposition to empty arrow param list elision.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
Andreas Rossberg wrote: On 14 March 2014 00:59, Oliver Huntoli...@apple.com wrote: JSC has been trying to kill off the initialiser expression in the for(in) statement, but we've encountered a bunch of reasonably significant content that breaks with it disallowed (a particularly prominent one currently is http://battlelog.battlefield.com/bf4/), so we will be bringing back support for for (var Identifier = Expression in Expression) I'd be curious to know what the actual code is, and to get an idea why they are using it that way. http://battlelog.battlefield.com/bf4/ for (var i = 0 in debug.audio) I say we should evangelize this site. Cc'ing some awesome Mozilla site evangelists. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
Brendan Eich wrote: for (var i = 0 in debug.audio) BTW, ur-JS in Netscape would not parse this. The optional initializer fell out of grammar over-reuse in ES1, possibly also works-in-JScript lobbying (my memory fades but that is where it came from). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
Geoffrey Garen wrote:
I suggested to Oliver that we accept Identifier = Expression in
Expression” as valid syntax, but drop = Expression” from the parse
tree after the fact.
Note that the issue here is only legacy that uses 'var' before
Identifier. So you can't be sure of no compat break, since
for (var x = 'haha' in {});
with no enumerable properties on Object.prototype will iterate zero
times, and the hoisted var x will be initialized to 'haha' and available
after the loop.
That way, we can still almost completely remove the construct from the
language without harming web compatibility.
I wish. But let's just evangelize the site, and any others that use this
botch from the ancient world (JScript = ES1).
I don’t see much value in making this decision based on strict mode.
So far, we’ve got nothing but trouble from policies like that.
I agree we shouldn't fuss with strict mode, it doesn't pay. We should
impulse-shoot the bad old form, right between the eyes, in ES6.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Initializer expression on for-in syntax subject
Peter van der Zee wrote: Which browsers currently don't accept this construct? I wasn't even aware that JSC didn't support it at some point. Did anyone say JSC lacked support? I think KJS followed ES3, and this was in the ES1 grammar, so I doubt it was never supported. Minifiers might rely on this construct. And perhaps some js1k entries, if that matters anything. Extremely doubtful. It doesn't save anything. A minifier cannot count on the loop iterating 0 times. Why is there a desire for banishment anyways? Only lack of consistency compared to not using the var keyword, This is only about the 'var' case. The initialiser in 'for (var x = y in z)' is due only to reuse of the wrong grammar nonterminal in ES1, based on JScript de-facto non-standard behavior. It is a wart and a pain to implement. We don't expect it to be hard to remove, unlike other warts, but we'll find out. or was there a bigger problem with this? The thread comes out of the blue to me so I probably missed a prior discussion :) ES6 revised the old grammar dating from ES1, breaking for(var x = y in z). That was intentional and discussed in past meetings and threads. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Typed properties beside Typed Objects
Andrea Giammarchi wrote: **Backward Compatible** Having an implicit default to `Any` means that this `type` descriptor property could be simply ignored or implemented as _always Any_ in ES5 or ES6 compatible engines but a simple library that wraps `Object.create`, Still not making sense. If the types can be ignored, then they have no effect when evaluating new code as well as old. Anything else is not backward compatible. Please slow down and show what you want to happen in new code that differs because of a .type member of a property descriptor. Show a use-case. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enriched Descriptors, maybe ES7 ?
Andrea Giammarchi wrote: I'd love to know more about Tom experiments on this! With his polyfill on the original proxy implementation, now that I think about it. https://github.com/tvcutsem/harmony-reflect but originally http://es-lab.googlecode.com/svn/trunk/src/proxies/DirectProxies.js Tom knows all. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enriched Descriptors, maybe ES7 ?
Andrea Giammarchi wrote: Although my idea is more about types You are starting on the wrong foot there. Types mean something in CS. Best if you start with use-cases instead of abusing the term. What code do you want to write, and how exactly would it operate? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
Tom Van Cutsem wrote: Given that most of the functions that use [[OwnPropertyKeys]] need to either construct an array anyway, or want reliable results, I wonder whether we shouldn't just change [[OwnPropertyKeys]] to include the checks and return an array instead of an iterable. That way we avoid having two internal methods that do more or less the same thing. +1. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptors(O) ? // plural
André Bargull mailto:andre.barg...@udo.edu March 6, 2014 at 1:21 PM I would rephrase into this: if you need a getOwnPropertyNames trap, you might need for consistency a getOwnPropertySymbols independently from getOwnPropertyDescriptors since these methods are already available. While it shares the same name with Object.getOwnPropertyNames(), this getOwnPropertyNames trap is supposed to return string and symbol keyed properties, see http://esdiscuss.org/topic/ownpropertykeys . Should the trap end in Keys not Names? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
Boris Zbarsky wrote: 1) document.styleSheetSets. 2) Microdata API. 3) Various places in indexeddb. 4) The DataTransfer API. 5) Some sort of offline resource list API that's not part of any standard I can find. #1 is not implemented by anyone but Gecko, and the spec is claiming it's a DOMString[], which no on implements at all. #2 is likewise not implemented by anyone but Gecko at this point, and the spec likewise claims DOMString[] (which again no one implements). For #3 I've heard Jonas claim he'd like to just moving ES arrays there. #4 is specced as a DOMString[], which again no one implements. What's with all the no one implements (including #3) stuff in specs? Are the specs new? Are we in a situation (even in #3, _pace_ Jonas) where the specs should be changed to reflect reality? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is, Can you try to find some sightings in the wild? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
John Barton wrote:
As you say all browsers seem to allow it. Browsers made the mistake
and we should not go back now and blame developers on smaller sites
because they use this kind of code. Make it a syntax error in modules
and save yourself a lot of headaches.
We could do this for sure, and in the absence of evidence that if (x)
function y(){} is used in the wild, we should. With such evidence, we
should. So, we should ;-).
But there's more to consider. IIRC, originally KJS (pre-JSC) in WebKit
did not support function-in-block or function-in-unbraced-consequent.
Then they added function-in-block support, bowing to the well-known uses
on the Web. When did they add function-in-unbraced, and why? Perhaps
someone can cite the fixed webkit.org bug.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Functions as blocks
On Mar 5, 2014, at 6:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 5, 2014, at 6:23 PM, Brendan Eich wrote:
John Barton wrote:
As you say all browsers seem to allow it. Browsers made the mistake and
we should not go back now and blame developers on smaller sites because
they use this kind of code. Make it a syntax error in modules and save
yourself a lot of headaches.
We could do this for sure, and in the absence of evidence that if (x)
function y(){} is used in the wild, we should. With such evidence, we
should. So, we should ;-).
But there's more to consider. IIRC, originally KJS (pre-JSC) in WebKit did
not support function-in-block or function-in-unbraced-consequent. Then they
added function-in-block support, bowing to the well-known uses on the Web.
When did they add function-in-unbraced, and why? Perhaps someone can cite
the fixed webkit.org bug.
We would have to come up with an an appropriate intersection semantics and we
don't have a base ES semantics to work off of as a function declaration is
illegal in that posiion in ES6. Would we also have to accommodate it for
IterationStatements and WithStatement
Right, it is not free - nothing around here is!
The other way to go optimizes for the reason WebKit folks added unbraced
support no longer applying: leave draft ES6 as is, implement and test among
major browsers, and see what comes out in the wash.
If no one else looks, I will try to find the WebKit.org bug trail.
/be
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Loader and Module as globals?
John Barton wrote: Well we have to make a choice. If we use Loader.prototype.Module, then we'll get System.Module by way of System being instanceof Loader. I don't see any reply to this message, but Loader and Module go in Reflect, last I heard. What you were worrying about does not make sense, so I say: don't worry. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Tom Van Cutsem wrote: By contrast, terms such as task are used much more broadly (e.g. tasks scheduled on a thread pool). Yes, and a Task (e.g., in Rust; akin to goroutine in Go or Process in Erlang) can be suspended voluntarily. The use of task goes way back (multi-tasking). I think we want a different word, not only to avoid confusion with respect to HTML5, but because JS event loop runs or turns really are different from those other tasks from CS literature and OS/PL research. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.of
Thanks for the pointer!
I like Claude's use-case and recall Allen citing it too. So, two reasons:
1. Higher-order functional programming wants a function, not literal syntax.
2. Subclassing Array works too, thanks to ES6's class-side inheritance.
/be
Rick Waldron mailto:waldron.r...@gmail.com
March 3, 2014 at 6:09 AM
On Mon, Mar 3, 2014 at 2:47 AM, Claude Pache claude.pa...@gmail.com
mailto:claude.pa...@gmail.com wrote:
Le 3 mars 2014 à 04:22, Mark Volkmann r.mark.volkm...@gmail.com
mailto:r.mark.volkm...@gmail.com a écrit :
What is an example of a use case where one would choose to use
Array.of instead of the literal array syntax?
Back when Dave Herman and I first dreamed up Array.of, I wrote this
up: https://gist.github.com/rwaldron/1074126#arrayof--variable-arity-
Rick
Here is one case where literal array syntax is not possible:
class ImprovedArray extends Array { ... }
let a = ImprovedArray.of( ... )
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Claude Pache mailto:claude.pa...@gmail.com
March 2, 2014 at 11:47 PM
Here is one case where literal array syntax is not possible:
class ImprovedArray extends Array { ... }
let a = ImprovedArray.of( ... )
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mark Volkmann mailto:r.mark.volkm...@gmail.com
March 2, 2014 at 7:22 PM
What is an example of a use case where one would choose to use
Array.of instead of the literal array syntax?
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 Tasks and TaskQueues
Allen Wirfs-Brock wrote: Now its just a word that we are assigning our own meaning to, so we can use turn if we want. But is that equivalence of turn and task really what you're used to, and something whose meaning is intuitive enough? On naming, we can use Turn instead of Task if enough people get it. I like it (much better than longer Activity which is quite vague in comparison, and even better than even longer ECMAScript Task). So +1 for Mark's proposal from me. More substantively, I'm concerned that you don't understand HTML microtasks but conjecture that they can be layered on top of ES tasks. I'm not necessarily faulting you alone here! The HTML specs I've read over the years at whatwg.org are maddeningly strung out and (I think) incomplete in defining tasks and microtasks. Perhaps they are better now. Who will understand both HTML and ES6 draft and make sure your conjecture is true? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.from and sparse arrays
Allen Wirfs-Brock wrote:
1. Array.from already produces sparse arrays from array-likes:
Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
So why it doesn't from sparse arrays?
Perhaps, this is an inconsistency that should be corrected by changing
the spec. to produce [1,2,undefined] in the above case.
No way. The object has length 3 and index 2 has value 2. Why in the
world would Array.from re-index?
The current definition was derived from the legacy algorithms such as
A,p.slice which preserve holes. But as the current consensus is
Array.from does not preserve hole for Iterable arrays then perhaps is
also should preserve them for non-iterable array-likes,
also should not?
At the last TC39 meeting, we agreed holes are freakish and should be
discounted in designing new APIs like Array.from (I think; I may be
overstating slightly, but that's the effect).
Whatever we do, we should be consistent among sparse arrays and sparse
arraylikes, it seems to me. Want a bug?
2. Array.from can't be used as generic plain array copy producer.
When this was most recently discussed at [1] the case was made that in
JS sparseness is seldom what anybody actually wants, hence the current
Array.from behavior will be what's desired most of the time. Do you
have any real world use cases in mind that are driving the desire for
Array.from to preserve sparseness?
Use-cases for sparse arrays + copying them would be really helpful.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: What does is not present mean in spec algorithms?
No informative deed goes unpunished, especially (as in this case) if it has contradictory normative implications! This was the lesson of ECMA-357 (E4X), with its overdone informative prose which often contradicted the normative prose. /be Sent from my iPad On Feb 21, 2014, at 3:29 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 21, 2014, at 3:16 PM, Brandon Benvie wrote: On 2/21/2014 3:08 PM, Allen Wirfs-Brock wrote: ``` Don't put too much weight into that. I've experiment with use the latter style when define some new methods to see where it is helpfully more descriptive. I just haven't bother to update all the legacy methods to use that same style. At some point in the near future I wall make a pass over the entire document and use consistent conventions for all function signatres -- either the ES3/5 style or the default value style. Given the amount of confusion the new style seems to have case, I may well revert to using the ES3/5 style. Isn't there a problem with the new contention because some steps are either implicit or aren't done? For example, `end = this.length` in the ES5 style would have explicit ToObject conversion on `this` before getting its length. Right, my intend wasn't that those signature should ever be read as in any way normative. The actual algorithm steps always explicitly describe the parameter defaulting behavior when it is anything other than just use undefined. Formerly we just would have used a signature heading like: Array.prototype.fill (value [, start [, end]]) it was hoping that something like Array.prototype.fill(value, start=0, end=this.length) would be more usefully informative. But in neither case is such a heading line intended to be an normative definition or syntactically valid JS code. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: .next('yo') in newborn generators
Bradley Meck wrote: Digging up old threads, but is there a way to test for newborn generators? No. To my knowledge they are the only iterable that does not allow a value to be passed in at a specific time. What do you mean by does not allow? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fwd: .next('yo') in newborn generators
Bradley Meck wrote: If I am reading the spec right (and I may not be), only the generator should fail? The first call to gen().next(value) must have value be undefined, and the others do not check. I thought we agreed at the January 28 meeting to get rid of this error, but I can't find it in the notes. The January meeting notes have missed other conclusions, though. Allen? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Return value of spec setters?
David Bruant wrote:
In practice, the returned value of setting is the value on the rhs of
the =.
var o = {set b(v){return 12;}} // this return statement is useless
console.log(o.a = 13); // 13
console.log(o.b = 14); // 14
It might be useful to return a different value on setting.
Just Say No.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Domenic Denicola wrote: Well, but you could just move the internal slot initialization into the constructor itself (as Scott has done in his es6-shim promises). Unlike e.g. `Array`, the objects returned by `Promise[@@create]` are not exotic objects; they are simply normal objects with some internal slots initialized. So the movement of code between `@@create` and the constructor does not impact very much. This is precisely the contentious issue, though. Should implementations be constrained to make Promises be normal objects with some internal slots initialized? If you subclass, you need the super's @@create to allocate the correctly shaped object, never mind setting the internal slots to default (undefined or nominal) values. Self-hosting a shim is nice, but it can overspecify. ES6 promises are not specified as self-hosted. Internal slots plus subclassability requires @@create. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
Claude Pache wrote: But I think that clarity can be improved by avoiding to obscure the intent by computation details. For my personal polyfill, I have found useful to abstract out the following steps, used (with slight variations) thrice in `Array.prototype.copyWithin` and twice in `Array.prototype.fill`, (and which can be used for various other methods of `Array.prototype`): IndexFromRelativeIndex(`k`, `len`, `default`) +1 Nit: How about just FromRelativeIndex for the name? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
C. Scott Ananian wrote: But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. Yet in that light you still have a point, I think. Allen? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote: Using -Speak as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Yeah, but no ECMA -- the double-whammy. Self-mockery is good. I pay my dues (see wat played with commentary at Fluent 2012 and narrated with tech details at Strange Loop 2012). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
C. Scott Ananian wrote: Are recordings available? http://www.infoq.com/presentations/State-JavaScript starting at 1:50 Youtube has more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Aside: ECMASpeak is neither accurate (we don't work for Ecma, it's JS
not ES :-P), nor euphonious. But here's a pointer:
C. Scott Ananian wrote:
new string object.
new string primitive, because string object (especially with new
in front) suggests new String('hi').
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Mark S. Miller wrote: I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I find it least surprising. vars hoist out of blocks. In non-strict code, functions leak out of blocks in ways that are hard to explain. I can understand non-strict direct eval as being block-like, in that var and function leak out of them, but all the reliably block-local declarations stay within the direct eval. Also, I buy the refactoring issue. It's like the problem with micro-modes: bizarre and unexpected non-local influences. Yes, agree on #3 being best. My recollection from past TC39 meetings and discussion here is that #2 will not fly. We do not want some let buried in a large string to eval to contaminate the whole eval'ed program such that vars in it are confined, where they weren't before. Just amplifying your refactoring point, but also noting your micro-mode/non-local comment. This is not going to win consensus. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: the various forms of eval are already micro-mode, so I'm not sure if those points are very relevant. No, the various forms of eval do not have non-local effects of the kind your #2 did! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loops, Let, Closures
Andy Wingo wrote: On Wed 12 Feb 2014 15:22, Thaddee Tylthaddee@gmail.com writes: The following ES6 code's behaviour puzzled a few developers I know. The results indicated below each snippet are run through SpiderMonkey's implementation. SpiderMonkey's implementation of for-let is out of date, AFAIK. I couldn't find a bug about it though. Could you please file one? ES6 specifies what Thaddee wants: a binding per iteration, and a 0th iteration binding in case there's a closure capture in the first part of the head. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Loops, Let, Closures
Andy Wingo wrote: On Wed 12 Feb 2014 15:55, Brendan Eichbren...@mozilla.com writes: Andy Wingo wrote: On Wed 12 Feb 2014 15:22, Thaddee Tylthaddee@gmail.com writes: The following ES6 code's behaviour puzzled a few developers I know. The results indicated below each snippet are run through SpiderMonkey's implementation. SpiderMonkey's implementation of for-let is out of date, AFAIK. I couldn't find a bug about it though. Could you please file one? https://bugzilla.mozilla.org/show_bug.cgi?id=971712 Cheers, Andy Thanks! I just remembered we have a bug on for(let in) and for(let of), https://bugzilla.mozilla.org/show_bug.cgi?id=449811 assigned to Jason. I hope this is all per draft spec (and we drop the E4X-era for-each(in) if we haven't already!). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Another switch
Definitely good to see new languages being designed and implemented.
JS is not going to break compatibility on the old fall-through behavior
of switch, inherited from Java from C++ from C. All the C-like languages
copy this flaw, because to do otherwise with the same keyword would be
worse (confused users cross-training and -coding among languages would
want our scalps), and IMHO using novel reserved words would be hardly
better.
/be
Nathan Wall mailto:nathan.w...@live.com
February 11, 2014 at 3:21 PM
Hi Giacomo,
Not sure whether this will be of interest to you, but I have been
working on a JS-derived language called Proto (still highly
experimental) which has a switch statement that works exactly as you
described:
https://github.com/Nathan-Wall/proto/blob/master/docs/control/switch.md
Perhaps you will at least find it interesting. :)
Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Giacomo Cau mailto:cau.giacomo...@tiscali.it
February 9, 2014 at 1:41 AM
Hello to all
I wish to submit a little proposal.
Today the switch statement has an
explicit break at the end of the statement and an
implicit continue to the next case
but this break is very boring and error prone.
Wouldn’t it be possible to think a switch that has an
explicit continue to the next case and an
implicit break at the end of the statement?
This is the hypothetical new statement syntax
with a new keyword:
hctiws ( ... ) { ... }
select ( ... ) { ... }
or without a new keyword:
switch ( ... ) break { ... }
but with the current switch equals to
switch ( ... ) continue { ... }
bye
Giacomo Cau
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: shorthand notation for attribute creation?
Good memory. This is all at esdiscuss.org in the meeting notes, but I
can't google for ||= to save my life, even in Verbatim mode. Anyone?
Of course the original proposal is still in strawman stage on the wiki:
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator
/be
Domenic Denicola mailto:dome...@domenicdenicola.com
February 9, 2014 at 12:49 PM
There was very active discussion, probably around 1.5 years ago, about
`||=` vs. a proposed `?=` (where `x ?= y` ≈ `x = x !== undefined ? x :
y`).
From what I recall some of the major points of discussion were:
- Should `?=` use `undefined` as its sentinel, or work with either
`null` or `undefined`? (This was before the behavior for default
parameters was decided.)
- Would adding `||=` be an attractive nuisance, when people should
be using `?=` instead?
- Given the existence of default parameters, and default destructuring
values, are either of these even necessary?
The last point, I think, was what killed both `?=` and `||=`. They
become much less necessary when you can write things like
```js
function f(foo = true, { bar = 5, baz = ten } = {}) {
console.log(foo, bar, baz);
}
```
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Andrea Giammarchi
Sent: Sunday, February 9, 2014 15:29
To: Hemanth H.M
Cc: es-discuss
Subject: Re: shorthand notation for attribute creation?
Unless I misunderstood your idea, `||=` makes me naturally think about
`+=` so if
`i += n;` means `i = i + n`
then
`o.name ||= value` means `o.name = o.name || value`
and this would be, according with all these years in ES3, the least
surprising behavior which is **way different** from checking if `name`
is not defined.
Accordingly, I wonder ...
1. what if `name` was inherited with a non _falsy_ value ?
2. what if `name` was defined as `undefined` ?
3. should that silently fail if `name` was already defined ?
Cheers
On Sun, Feb 9, 2014 at 2:17 AM, Hemanth H.M hemanth...@gmail.com wrote:
Something like `var foo = {}; foo.bar ||= 3` would be very useful.
But not sure how something like `obj['name']['maxlength']` be reduced
to shorthand check if 'name' is not defined.
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
February 9, 2014 at 12:29 PM
Unless I misunderstood your idea, `||=` makes me naturally think about
`+=` so if
`i += n;` means `i = i + n`
then
`o.name http://o.name ||= value` means `o.name http://o.name =
o.name http://o.name || value`
and this would be, according with all these years in ES3, the least
surprising behavior which is **way different** from checking if `name`
is not defined.
Accordingly, I wonder ...
1. what if `name` was inherited with a non _falsy_ value ?
2. what if `name` was defined as `undefined` ?
3. should that silently fail if `name` was already defined ?
Cheers
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Kevin Smith wrote: If I may interject some opinions on process... Sure, it's es-discuss. Plus, you've earned your spurs. I'm not sure how this fits in with the new post-ES6 process, but from this one outsider's point of view: - A formal set of design goals should be completed and agreed upon before design work is begun. The design goals form the basis of measurement and the champion(s) must be bound to them at all times. Any changes to the design goal document must be carefully reviewed in order to prevent churn. A detailed change-log is an obvious requirement. Sounds both good in principle, and bad like waterfall. Waterfall is dead. Would such goals have helped promises? I bet we would have fought over the goals, at best. At worst, we'd agree to vague goals and end up where we ended up. - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. Yes, this. On a side note: it seems to me the the existence of the design champion, who by definition is deeply invested in the design process, implies the existence of its dual: the anti-champion, who is detached from the details of the design work and provides a vital holistic perspective. Yes, the _advocatus diaboli_. We have plenty of those, though. Too many, at this point. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
David Bruant wrote: Le 07/02/2014 22:05, Brendan Eich a écrit : Kevin Smith wrote: - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. Yes, this. A working implementation is a lot of work, even a polyfill. But tests. Very recent case in point : https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 It was a lot of words in English, lots of HTML5 spec vocabulary with very special and detailed meaning, I had lost track at some point, even with the spec-y summary by Bobby [1]. But then, he created tests and that was suddenly fairly easy to review [2]. It was fairly easy to point places that might be under-spec'ed and needed more tests. Yeah, a warning to auto-didactic prose-heavy spec authors. Tests are an excellent medium to discuss feature design. The current test suite leaves room for interpretation on a corner case? throw in a new test to disambiguate! Tests++. Until they overspecify, then --. No silver bullets. More tests when in doubt. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Quildreen Motta wrote: but as with other parts of JavaScript, the simpler, orthogonal primitives are not available for users to derive more complex functionality from easily. So true. JS is like a mini-toolkit of three-tool Swiss Army Knife (functions) with constructor and closure tools as well as the big first-class function edged tool; and super-caulk (objects) usable in a pinch as adhesive as well as sealant. Kind of what you want when you are traveling light, in a hurry running from zombies, no time to get a proper toolbox. Part of TC39's work has been decomposing some of the multi-tools into new forms that do one thing well (arrow functions are my favorite in this regard). But it is both hard to justify the effort, and actually a lot of effort, to decompose fully in all cases. Still I agree with Paolo. If we had functional (even value-like, featureless, then-able only via a special form, as in E) Futures, we could rebuild Promises on them and let Promises remain the library they've always been. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Domenic Denicola wrote: The amount of heat Kevin has piled on to promises-unwrapping, repeatedly, has been puzzling and unwarranted, but I have chosen mostly to set it aside, as the words of someone who did not care to understand the whole history and design constraints involved in writing this spec. Apologies for seeming to side with Kevin's shenanigans, that's the wrong word. I shouldn't have cited it without noting how it usually implies bad intent. What I was reacting too, perhaps Kevin is as well, is the difficulty in getting something seemingly simple (as library code) standardized. And you're right, there was a lot of hard work to get to where we are. Thanks for all you've done. I am in no position to complain, having stayed away from the long promises threads over the last many months, mostly. But (and I fell for this too, no excuses) combining two conflicting APIs into one proposal was always a mistake. Andreas R. argues we can live with the over-wrapping in resolve, and seems to argue that my higher priority points (1, committee do both error; 2, .all etc. use .then not .chain) are either not problems or minor enough to live with. Ron Buckton just proposed a do both solution that is at least properly parameterized in the constructor, so combinators (2) work. But it's still a stinking optional state flag that forks runtime semantics and API reasoning chains (1), creating bug habitat and probably pleasing no one much. My realism argument seems strong, and your summary backs it: DOM was only using .then and .resolve, that's all they needed. That's all library Promise users use, in general (please correct me if I'm wrong). That is what Promises are in a real sense that constrains our standards efforts for ES6 and the DOM. HTH, and thanks again for all your work. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async decision making (was Re: Promise.cast and Promise.resolve)
Edward O'Connor wrote: Perhaps TC39 should consider adopting a similar policy. Policy, schmolicy :-P. (Presumably clocks with deadlines are required; consensus could break afterwards, in spite of the formal rules.) Let's let our hair down a bit and get real here. We did not declare consensus Thursday last week, in any formal or informal fashion. We knew Andreas wasn't there. We heard his position articulated by Sam (who dialed in). We knew most of what we now know. At this point we must forge async consensus. Is Andreas and anyone else (I'm not singling him out; I sympathize and started on his/Sam's/Kevin's side earlier last week) objecting doing so in a consensus-breaking way, for sure? We should async-check this. Often one objects or finds a survivable fault in a consensus position, and works to persuade others to overcome it. Sometimes this leads to minimization (and over-minimization) and deferment of troublesome but important bits (@medikoo on twitter reminds me we dropped .done after June's big thread -- a semi-consensus deferment, I found from (re-)reading a bunch of messages). If we really have broken consensus in the async sense, we will have to back up to Kevin's fixup of AP2, as Mark suggests. I have no idea how this will shake out. I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto quasi-standard we are trying to codify, not green-field work where we can start over or do both. Is any of this persuasive to anyone? Dunno, you tell me. If DOM only wanted .then/.resolve, you should join my realist camp :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async decision making (was Re: Promise.cast and Promise.resolve)
Alex Russell wrote: I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto quasi-standard we are trying to codify, not green-field work where we can start over or do both. Excited to hear someone else recognize this reality. Another realist! I will subscribe to your newsletter if you will buy my cereal! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Tab Atkins Jr. wrote: Note, though, that you can still have consensus*and* strong objections. Design-by-committee is still a failure mode to be avoided. Excellent point. Argues against do both. Can't ditch .then/resolve given library code interop constraint. That forces the conclusion from last week's meeting. What do you think at this point? My Futures cereal next year will be delicious and nutritious! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Tab Atkins Jr. wrote: (Fixing it does involve magic, or subclassing, but those are things that can be done internally, rather than exposed to authors as terrible API.) Could you say a bit more? Do you mean APIs that defensively hand-box so the user doesn't have to, with async map and its overloaded get return value? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Tab Atkins Jr. wrote:
The APIs for Caches and dealing with responses are designed so that
they work nicely together, acting the same way whether you pass a
Response or a PromiseResponse. So you can often respond to requests
with a simple e.respondWith(cache.get('foo')) and it Just Works®.
Nice.
But say you wanted to do something a bit more complicated. For
example, if the cache hits, but the result is a Promise, you might
want to show a throbber until the Promise resolves. Under the old
consensus, you could do this pretty easily - just do
cache.get().chain(...) and then operate on the result. Under the
new, you can't, because the cache promise won't resolve until after
the response promise resolves. We can't say just hand-box, because
it breaks the easy pattern above when you*don't* want to do anything
complicated - you have to .then() it and unbox there.
Yeah, that would suck for the pretty one-liner. But is it really that
much more? Write it out and let's see A vs. B.
There are various ways to work around this. One way is to
auto-handbox:
Heh, an oxymoron, like Military Intelligence.
But I know what you mean!
we subclass Promise to CachePromise and hang a .chain()
off of it which receives the actual value you stored in the map, while
.then() silently unboxes and continues flattening as normal. Another
way is to just guarantee that Cache promises never hand promises to
their callbacks, and ensure that there are alternate ways to check if
a Response is ready yet (maybe just forcing people to more explicitly
track the Response promises directly, and make sure they're synced
with the stuff in the Cache).
Sure, there are longer ways to go, but they seem to require if-else's or
similar. I still would like to see the A-B test.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Tab Atkins Jr. wrote:
On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldronwaldron.r...@gmail.com wrote:
Per Resolution
(https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3)
- Promise.cast is renamed to Promise.resolve (remove old Promise.resolve)
- Keep then, reject chain (NOT DEFER, reject!)
- Renaming .cast thus removes over-wrapping (always-wrap) deoptimization in
old Promise.resolve
Okay, so this is discarding the previous consensus, right? Monadic
promises are thrown out?
Fundamental conflict between .chain and .then, on three levels:
1. Committee do both / union proposals smell and bloat -- this is a
problem _per se_.
2. All the standard combinators call .then not .chain.
3. Including .chain requires always-wrapping resolve, observability
trumps optimizability.
There's really a 0 implicit in this:
0. Monadic vs. non-monadic is an exclusive or -- you can't have it all.
This breaks async maps forever, then. :/ With the previous consensus,
the result promise from an async map could be observed directly with
.chain(), and it worked great regardless of what was stored inside the
map.
With only flat promises, if you store a promise in an async map and
then try to retrieve it later, the error callback gets called if the
key wasn't in the map*or* the key was in the map, but the stored
value was a rejected promise. You have to spread your program logic
over both callbacks to catch that case (or more likely, people will
just write programs that break occasionally because they assumed that
the reject branch of the AM.get() promise is only for failed lookups,
as the documentation probably says).
This does seem like a problem in the async map API, but I bet it can be
solved without taking the hit of 1-3 above. Overloading get's return
value is the root of the evil. Hand-boxing disambiguates the r.v.
Similarly, if you store a forever-pending promise in the async map,
it's impossible to ever retrieve it. Even just a long-pending promise
will stall your program's logic while it waits, preventing you from
updating UI when the map returns and*then* completing the operation
when the stored promise finally resolves.
This, I don't buy. You have to hand-box using {value: } or whatever.
The only way to get a working async map is to defensively store your
values in a single-element array (or some other non-promise wrapper
object) and unwrap them on retrieval.
Right, hand-box. That's the price of the XOR between Monadic and
anti-Monadic promises, and anti-monadic already won in the library
evolution of Promises.
Pretending that all promises are identical identity-less wrappers that
can be arbitrarily collapsed is such a mistake._
There are no great paths forward. I would like to make promises value
objects, E-like. But it's too late. Promises happened, the DOM and ES6
need them, worse is better. You knew that already!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
mfo...@eldergods.com wrote: #3 is the only point I concede as being even possibly concrete Then you get a *plonk*, or at least a demeric, for ignoring the very concrete problem #2: combinators such as .all do not use .chain, they use .then. Also for ignoring #1 -- it doesn't matter that .then is compound, complex, multifarious -- it's a de-facto standard. And it is what combinators (#2) in the standard use, so you can't ignore the committee bloat or unioning cost. Imagine we simplified to do just .chain and .cast, and combinators called .chain. We'd be breaking compatibility with extant promises libraries, and de-jure future-banning .then/.resolve as an API alternative. The existing promises library users would be faced with a porting problem whose size is hard to estimate, since they are relying on assimilation and unwrapping happening behind the scenes. Promises *happened*. They are real. That's why I tweeted about #realism. Wanting something value-ish, featureless, monadic, is a good goal for a differently named abstraction built on value objects. Promises are not that abstraction. Do the work to show the win, under a new name (Future?). Until then this is selective arguing and cheap talk. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Brendan Eich mailto:bren...@mozilla.com February 4, 2014 at 7:46 PM Then you get a *plonk*, or at least a demeric, demerit', of course. But I'm talking to a fake address. That's pretty bad, it makes me want to ignore you (*plonk* in USENET terms). Do better quickly, or else that's the right outcome. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Mark Roberts wrote: Wanting something value-ish, featureless, monadic, is a good goal for a differently named abstraction built on value objects. Promises are not that abstraction. Do the work to show the win, under a new name (Future?). I believe the win has already been shown, though: Futures would of course give you the same thing Promises do while supporting those additional use cases where you don't want recursive unwrapping. No. Future as a featureless value object would not have any of the identity-based problems reference types including Promises have. It would become its result when fulfilled. You would not be able to do much with a Future other than then it. There would be no thenable assimilation via duck-typing of thenables. #2: combinators such as .all do not use .chain, they use .then Is this such a big deal? If you have .chain then you have .then, so you can certainly have it all. That .then would be based on .chain is irrelevant. Anyone using .all would not get .chain and would potentially depend on all the .then magic. Purists trying to use only .chain would need to write their own .chainAll, etc., which would not be in the standard. Imagine we simplified to do just .chain and .cast, and combinators called .chain. We'd be breaking compatibility with extant promises libraries IMO, leave .all and the rest of the combinators as they are using .then. I would not mind so long as .chain is intact. See above. This does not wash unless you aren't using combinators at all, or you are rolling your own -- in which case we have a bloated do both forked standard. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
