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
Allen Wirfs-Brock wrote:
[ object ???]
[object WTF]
:-P
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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;
}
}
```
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
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
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
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?
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
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
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,
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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®.
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)
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
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
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
501 - 600 of 4618 matches
Mail list logo
