I am generally against sacrificing things for polyfillability. I'd rather say
if you're using this polyfill and need security guarantees, use `Promise.as`
(or `Q`, even); if you want forward-compatibility at the expense of security,
use `Promise`.
Other options could involve using the module
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Unless you wanted promise-likes to return fresh objects too?
Yes, that is largely the use case for `Q`/`Promise.as`/whatever. Handing it
untrusted input, possible a non-promise, possibly a promise-like, possibly a
promise, and getting back a
Indeed, nice catch Anne. I guess it's an unfortunate necessity that the monadic
stuff will need to drag along two methods, not just one.
A name like unit (or perhaps of) seems to fit better in my mind, than
introducing another natural-language verb like accept. Especially since it
will be used
From: annevankeste...@gmail.com
In particular, what *kind* of unwrapping does then() do on the input and
return side (ideally expressed in pseudo-code).
I believe this comes down to the as-yet-unresolved conversation about thenable
assimilation vs. branding and such. In any case, it should
From: Mark S. Miller [erig...@google.com]
No. Assuming that p and q are both promises and that q is pending, p is
resolved to q when either p adopts q or p accepts q. From the .then
perspective these are the same, so we'd say p follows q or p is resolved to
q. In neither care would p.then
Er, replace `notAcceptedAndNotResolved` with `resolvedButNotAccepted`. X_x
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus
following errata) I created the following promise:
```js
var foreverPending = new Promise(() = {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```
This brings up the horrible point that
I don't really understand your response. What timeouts are you talking about?
(Wrong thread perhaps?)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mark, I completely agree with you. However, I think this somewhat ignores the
issue of this thread. The problem with AP2, even completely ignoring `flatMap`,
comes when you consider the behavior of the `Promise.fulfill` method. Namely,
what does this code do?
```js
var foreverPending = new
Actually, I think it'd be fantastic to have an easy way to communicate required
parameters in an options object. It's a fairly common pattern; for example in
the S3 library knox that I maintain we require bucket, key, and secret, but
everything else has defaults.
Woah. I was sad about the loss of refutable destructuring, i.e. I would rather
have had it by default, but this idea is a pretty brilliant way to make
lemonade out of lemons. I would *love* a way to declaratively specify required
parameters.
___
The clamping inside nested callbacks prevents setImmediate from being as good
at this job as postMessage or MessageChannel
Er, prevents setTimeout(..., 0) from being as good...
___
es-discuss mailing list
es-discuss@mozilla.org
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
From what I understand, setTimeout 0 serves that use case and there is no
reason for setImmediate to be better at this job.
This is not true, as can be seen from
http://domenic.me/setImmediate-shim-demo/. The clamping
Right, +1 to both of Forbes's points.
I think the essential equivalence I want to get across is between microtasks
(`window.asap`) and synchronous loops. If there is a better solution than the
slow-script dialog for such scenarios, great! Maybe we can use it in future
APIs like `window.asap`,
From: Forbes Lindesay [for...@lindesay.co.uk]
Why so?
I think it was something Domenic Denicola said that I'm remembering, but
don't the extremely short timeouts mean more work (and thus power) for the
CPUs timer. I'm sure I remember reading something about timeouts less than a
certain
Hmm, interesting!
I wonder if it could be event simpler than that, and after an arbitrary limit
(in time, not number of microtasks), just reschedule for the next event loop
turn's microtask phase. For promise applications there is no problem with this;
I am not sure however if that is an
(Forked from a public-script-coord thread; thought it would be useful to
es-discuss as well.)
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
On Aug 7, 2013, at 12:33 PM, Boris Zbarsky wrote:
Just to make sure I understand the behavior of @@create: it can be invoked
to create new objects,
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
Which of these questions are still unanswered by the above doc?
Wow, it was a good document; I'm sad I forgot about it.
I think what's still missing would be some guidance, on when it's needed in
designing platform classes or user classes, and
Right, I think both are indeed enums at some conceptual level. IDL gives that
concept a name; ES does not. It would be nice if IDL enums followed ES
semantics, of doing `ToString(value)` (which may throw a `TypeError`) and then
throwing a `RangeError` if outside the allowed range.
However, the
From: Erik Arvidsson [erik.arvids...@gmail.com]
We went through the exercise of only having private symbols but it lead to
some issues. Here is one that we identified.
Lets assume we use a private symbol for the @@iterator. The symbol can still
be checked because anyone that has access to
From: Brandon Benvie [bben...@mozilla.com]
That would leak the Symbol to the Proxy and then private Symbols wouldn't
carry a guarantee of security. That's the only difference between private
Symbols and unique Symbols.
Right, I thought about that, but I am still not quite clear on what the
Thanks Brandon. As I expected, obvious once you see it. Hopefully my learning
experience was helpful to other observers too :).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From: Mark S. Miller [erig...@google.com]
A good start would be to convert
https://github.com/promises-aplus/promises-tests to test262 form, extending
test262 in the process in order to accommodate async testing. Any volunteers?
If someone does the latter (preferably with a simple
Just some terminology questions for this new proposal...
From: Tab Atkins Jr. [jackalm...@gmail.com]
whatever p resolves to, gets passed to the flatMap() callbacks.
What does resolves mean in this context? I don't believe you are using it in
the same way that it is used in Promises/A+ or DOM
org.ecmascript.es6.builtins.iterator?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From: Tab Atkins Jr. [jackalm...@gmail.com]
For the purposes of this email, a promise accepting or rejecting means
that its resolver's accept() or reject() method was called, or the equivalent
internal magic. fulfill means accept or reject. resolve means adopt
or accept, depending on
From: Mark S. Miller [erig...@google.com]
One thing I think Domenic is missing that I also missed at first: Once we
introduce .flatMap, then we need a distinct accepted state that is neither
fulfilled nor rejected. The issue is that p.then does not fire until the
promise p is fulfilled or
From: Mark Miller [erig...@gmail.com]
On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Mark S. Miller [erig...@google.com]
One thing I think Domenic is missing that I also missed at first: Once we
introduce .flatMap, then we need a distinct accepted
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
BE: Why can't we just have (private) Symbols
BE: Can we unwind the split between private and unique?
These struck a chord with me. Thus, in the spirit of
BE: We aren't going
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
Why is setTypeOf attached to Function? There would seem to be very little to
naturally associate it with Function. I suppose it's because that's where
you put 'defineOperator'. Even there, the association with Function seems
tenuous. I
I agree a missing body is usually weird; the only case that really makes
sense is `=`, which is especially useful in default parameter lists:
```js
function tryCatchFinally(tryF, catchF = =, finallyF = =) {
// ...
}
```
From: Axel
Why do arrow functions require a parameter list and a body? That is, none of
the following are allowed:
- `= foo`
- `bar =`
- `=`
Instead you need the more-verbose
- `() = foo`
- `bar = {}`
- `() = {}`
Any chance of relaxing this a bit?
___
From: Oliver Hunt [oli...@apple.com]
I guess this could be lexically unambiguous, but i'm unconvinced that the
win of losing two characters in the strictly less common no parameters is
worth the syntactic confusion
No-parameter functions are pretty darn common, especially if you count cases
From: Brendan Eich [bren...@mozilla.com]
I proposed arrow functions and championed them into ES6. As the strawman
history shows, eliding () and {} were both supported at first:
Right, I remember `{}` being optional at least; in fact the genesis of this
thread was me working with Traceur this
From: Andy Earnshaw [andyearns...@gmail.com]
if pragmas are to be entered into the specification
They are not.
then it could even become part of
use strict;
Or even better: it could become part of `./andys-transpiler myfile.andy`.
___
From: Brendan Eich [bren...@mozilla.com]
You still value the
```js
(x == y typeof x == y) = x === y
```
invariant, right? That's the motivation for decimal, int64, etc. having their
constructor-named decimal, int64, etc., typeof-result strings.
You have brought up this invariant in
From: Anne van Kesteren [ann...@annevk.nl]
Is there a better way?
```
video.startDate() !== video.startDate()
```
?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From: Brendan Eich [bren...@mozilla.com]
Yes, and I've written about why invariants matter on occasion -- perhaps you
missed that :-P.
Heh, 2008 was before my time. But generally yes, I certainly understand the
importance of invariants. I am just not sure this particular invariant is
I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
would do the trick, since `Object.freeze` seems to set all property keys to
non-writable/non-configurable.
This seems like it would be a backward-compatible change. But it's so simple I
imagine it's been discussed
From: Domenic Denicola [dome...@domenicdenicola.com]
This seems like it would be a backward-compatible change.
Well, OK, this is actually just false: code that previously did
`Object.freeze(dateObj); dateObj.setDays(3);` would no longer work as expected.
I guess that might kill this idea
From: Brendan Eich [bren...@mozilla.com]
No wrapping object type -- those are legacy, to be avoided. See
http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing
is value not reference semantics.
Hmm, is `0UL.toString()` not possible then? What about `0UL + `?
I believe duplicating the `Array.prototype` built-ins as generator versions, in
user-code, is the expected path forward. Perhaps an itertools-like module
will be standardized and added in ES7, after that cowpath has been paved.
This pain is somewhat alleviated by generator expressions (which
While I sympathize with the desire to make integer mean mathematical
integer, I don't think it's going to work out very well. Nobody actually cares
about such functions, and you of course have the WATs of
```js
Number.isInteger(9007199254740992.5) === true
```
since the runtime couldn't
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Exactly, which is why we can only *accurately* answer for numbers = 2^53-1.
Probably a horrible idea in practice, but I feel like the correct answer here
is `throw`ing outside that range. It's like asking is Tab's second head blonde
or
Woah, François, that seems pretty overcomplicated; why not replace everything
inside the constructor with `this.message = message`? It has the same effect in
the browsers I've seen. (Also don't forget `SomeError.prototype.constructor =
SomeError`.)
Anyway, to Jonas's point: I think `DOMError`
From: Jonas Sicking [jo...@sicking.cc]
Note that
```js
(new DOMError) instanceof Error;
```
returns false. So the DOM does do the strongly discouraged thing. Is this
ok or bad?
This is horrible! I had no idea! It should definitely derive from `Error`.
Also, the DOM does not create a
From: Kang-Hao (Kenny) Lu [kangh...@oupeng.com]
Are you sure? What libraries do that?
Well, jQuery's a pretty famous one.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
From: Rick Waldron [waldron.r...@gmail.com]
Regardless, I support your claim. It's not that library authors use this
pattern in all constructor definitions, all the time—it's a pattern used by
responsible authors when creating constructors to ensure user code will just
work, whether
From: Axel Rauschmayer [a...@rauschma.de]
Curious: is that an important distinction? To me, a (sub)class is the
implementation of a (sub)type.
This doesn't make much sense in an ES context, where the only
[types](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-4.3.1) are
Undefined,
Given that all non-primitive built-ins behave this way, and that including `if
(!(this instanceof ConstructorName)) { return new ConstructorName(...args); }`
is a well-established best practice for ES5 code: can we just do this
automatically for classes declared with `class`?
FYI this thread honestly feels like you're trying to get more people to watch
your video and use your library. I'm sorry not enough people are using/watching
your stuff, but this mailing list isn't really the place to push it.
On Jun 29, 2013, at 8:58, Eric Elliott
From: Claude Pache
implement/polyfill the iteration protocol in both old and new environments,
using `GetIteratorSymbol()` where @@iterator is needed. If that
`GetIteratorSymbol()` function is readily available in a standard place, it
will allow different libraries to cooperate.
I think
From: Allen Wirfs-Brock [al...@wirfs-brock.com]
My recollection is that we first discussed that the existence of Array.from
make this issue somewhat less important because, just as you point out, .from
can be used in conjunction with anything that produces an Iterable such as
From: Rick Waldron [waldron.r...@gmail.com]
One reason is the extra allocation...
It's not at all arbitrary: filter isn't an operation used to change the value
of the items in the returned iterable.
OK, I think I see. This is because `NodeList.prototype.map` behaves differently
from
Thanks Allen. The
```js
var squaredSmalls_try2= Int16Array.from(smalls.map(v= v*v)); // still no
good, because intermediate array is Int8Array
```
example certainly clears it up for me. Tricky stuff.
I was going to write it's still a bit weird to me that we overload
`Array.from` with
From: Alex Russell [slightly...@gmail.com]
On Wednesday, June 19, 2013, Ron Buckton wrote:
Promise#done() doesn’t have the overhead that Promie#then does (allocating a
new chained Promise), so it is more efficient if you don’t need to chain.
That is my only latent argument for #done(), and
The logging solution proposed is not polyfillable with today's tools, at least
not when logging to the browser console.
The idea would be that rejection reasons are logged when nobody has handled
them, but then un-logged when they are handled. Since there is no
`console.unlog`, you see our
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Kevin Smith
To this end, in my own promise implementation I use a form of fail soon,
like so:
It sounds like this does not support handling rejections in an event loop turn
after they are generated,
From: Mark S. Miller [mailto:erig...@google.com]
I don't understand this. I am onboard with
`console.unhandledRejection`/`console.rejectionHandled` and all that for
better logging, and with using WeakRef notification to improve the logging
yet further. But I don't see how any of this can
From: Sam Tobin-Hochstadt
This is close, but not quite right. The rule is that any unbound variables
in modules are errors. The variables may be bound by import declarations, or
by lexical bindings such as `var` or `let`, or by bindings on the global
object, or by top-level `let`
From: Mark S. Miller [mailto:erig...@google.com]
What do you think I'm getting at? ;)
Heh. In short, non-browser environments.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It seems es-discuss receives a lot of these emails, bikeshedding the behavior
of `Object.mixin` from people with preconceived notions of what a mixin is
and what a mixin function should do, how it should integrate with class syntax,
etc. In contrast, when it was just `Object.define`, it was
I found this comparison with C# illuminating, trying to make sense of this
thread.
- It uses duck-typing for its `foreach` loops, allowing them to work with
anything that has a `GetEnumerator` method.
- All of its collections do have this, by virtue of inheriting from
`IEnumerable` or
From: David Herman [dher...@mozilla.com]
Moreover, Yehuda has urged me to consider
export x = 17;
as sugar for
export let x = 17;
I'd urge `const` instead of `let`, as `const` discourages the footgun of
action-at-a-distance mutable `with`/global-like bindings that I keep talking
From: Yehuda Katz [wyc...@gmail.com]
In general, expectations about side-effects that happen during module loading
are really edge-cases. I would go as far as to say that modules that produce
side effects during initial execution are doing it wrong, and are likely to
produce sadness.
In
From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam
Tobin-Hochstadt
The idea here is that modules will typically be written in files like
compiler/Lexer.js, where the starting grammar production *is* `ModuleBody`.
Ah, that makes sense! It's a nice way of prohibiting
I really dislike `export =`. It looks like it should be creating a global
variable named `export`.
`export default` is perfect IMO. It also conceptually fits better with how
default exports work. (I.e., they're *default* exports, they're not the
entirety of the exports. They don't overwrite
Sam was saying that http://wiki.ecmascript.org/doku.php?id=harmony:modules is
up to date. If so, I'm seeing a few things missing from the BNF. It would be
great to get these clarified so people can start writing accurate transpilers.
1. It looks like `ExportDeclaration` can only occur inside
From: Tab Atkins Jr. [jackalm...@gmail.com]
NodeList is an interesting case, actually. It's an Array, but with a type
restriction.
What do you mean by that? Surely you don't mean can only store nodes:
```
var nodeList = document.querySelectorAll(div);
undefined
nodeList.length
22
I found it [a fun exercise](https://gist.github.com/domenic/5632079) to show
how little code it takes to build unabashed monadic promises on top of Q-like
promises. (It's been a while since I exercised those brain-muscles, so any
corrections appreciated.) The punch line is
```js
function
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Thoughts?
Sounds like a great user-space library!!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It also adds a fulfill method. Thus, it presents two interfaces to the user:
fulfill + chain (aka unit + bind), and Q + then (aka resolve + then). This
seems to squarely fall into the trap Mark described in his original post, viz.
The main failure mode of standards bodies is to resolve a
Seems like this isn't really a Map? It'd be pretty confusing for something to
pretend to be a Map but act in such coercive and side-effecty ways. Better to
just obey the Map structural type, perhaps, to give people an interface they're
used to while not pretending to be something you're not?
` works for any `x`
and `y`, then you're probably fine.
On May 21, 2013, at 1:16, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, May 20, 2013 at 7:55 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Seems like this isn't really a Map? It'd be pretty confusing for something
to pretend
On May 21, 2013, at 1:23, Anne van Kesteren
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Tue, May 21, 2013 at 6:20 AM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
As long as the contract that `map.set(x, y); map.get(x) === y` works for any
`x
On May 21, 2013, at 1:28, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, May 20, 2013 at 10:20 PM, Domenic Denicola
Isdome...@domenicdenicola.com wrote:
Oh, I must have misread your original message. I thought it did not allow
storing non-string keys. If it can allow storing any kind
From: Jason Orendorff [jason.orendo...@gmail.com]
Here's what you would do under the proposal:
```js
// import a module in the same package/project
import ./controllers as controllers;
// import some other package
import backbone as backbone;
```
The surface syntax deliberately follows
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt
[sa...@ccs.neu.edu]
How is this in disagreement with what Jason said? His point is that if
you're in the module a/b/c, ./controllers refers to a/b/controllers,
and backbone refers to backbone.
Ah, I see, there are
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt
[sa...@ccs.neu.edu]
In contrast, usually you want to be using that global version of backbone,
not something specific to your library. Of course, you can bundle backbone,
and refer to it with ./backbone if that's
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt
[sa...@ccs.neu.edu]
There's a default place to fetch files from, because there has to be _some_
default.
Why?
This is the core of my problem with AMD, at least as I have used it in the real
world with RequireJS. You
From: James Burke [jrbu...@gmail.com]
On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
This is the core of my problem with AMD, at least as I have used it in the
real world with RequireJS. You have no idea what `require(string)`
means---is `string
From: Mark S. Miller [erig...@google.com]
Much as I hate to say this, but if all major JS platforms support some
harmless feature, cross-browser web content will come to depend on that
feature. In that case, we are better off doing the work to codify an agreed
common behavior for that
I think one point that's being hinted at, but not explicitly called out, is the
confusing nature of `import foo` in the proposed scheme. Notably, it shares
this confusion with AMD, but not with Node.js.
The problem is that `import foo` can mean *either* import the main module
for package with
From: Sam L'ecuyer [s...@cateches.is]
These may all be wrong, but all seem to be hitting at the fact that in a new
turn is the *easiest* way to force asynchronicity. Maybe we need to specify
that all callbacks must be invoked asynchronously, regardless of which turn
in the event loop they
From: Tab Atkins Jr. [jackalm...@gmail.com]
I think you're making this far too complicated. It's much simpler than this:
I disagree. An abstraction boundary gets broken. Consider:
```js
function getUser1() {
return doXHR(/user.json);
}
function getUser2() {
return { name: domenic };
}
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Jonas Sicking
It isn't actually surprising that the same issues arise. ProgressFuture
basically delivers progress about an operation rather than a result.
I agree. I think both progress and cancellation
While this is starting to make a lot of sense to me, especially the
package-vs.-module concerns, I worry about trying to get it in ES6. Also, as
someone with an ES5 background, I don't see the value of lexically-named
modules, and so am happy to postpone them to ES7.
Taken together, I think
So there are no such libraries, and you are just wishing that they existed and
that they took over the meaning of `then` from promises?
From: Claus Reinke [claus.rei...@talk21.com]
Sent: Friday, April 26, 2013 10:11
To: Domenic Denicola; Mark Miller; David
From: David Bruant [bruan...@gmail.com]
Thoughts?
Since this entire problem seems predicated on Claus's misunderstanding of the
term thenable, which apparently has no basis in real libraries but instead
entirely in wishful thinking, it might be more prudent for him to use the term
monad
From: David Sheets [kosmo...@gmail.com]
From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
`FutureResolver`.
This is not correct. See Let resolve be a future callback for the context
object and its resolve
From: Kevin Smith [zenpars...@gmail.com]
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you see
that working? From a namespace perspective, how is that any different than
hanging identifiers off of
From: David Sheets [kosmo...@gmail.com]
Why is there a semantic distinction between my thenables and your thenables?
Because your thenables are not to be trusted! They could do pathological things
like jQuery, or conceptually incoherent things like thenables-for-thenables.
Sanitation at the
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and libraries
switch to using those (or a subclass of them) rather than rolling bespoke
promises.
Last I heard, jQuery has committed to never switching their promises
implementation to
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound that hard (library authors can jump in to say
From: Juan Ignacio Dopazo [dopazo.j...@gmail.com]
2013/4/26 Kevin Smith zenpars...@gmail.com
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only one layer, the spec would need a way to
discern
From: Kevin Smith [zenpars...@gmail.com]
Yes, sorry. It will on version 1.1:
https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure
To clarify: in 1.0, the behavior of returning a thenable was highly
underspecified, in part because of a lack of clarity about
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be
compatible with Promise/A+ and not jQuery promises? Because more libraries
use Promise/A+? what about market share?
What we're discussing is not *compatibility* but *ability to
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to actually
provide an example of where flattening is useful, that isn't (a)
assimilation, (b) a result of weird language semantics from some non-JS
language, or (c) an authoring
Can you point to any code in wide use that makes use of this thenables =
monads idea you seem to be implicitly assuming? Perhaps some of this generic
thenable library code? I have never seen such code, whereas the use of
thenable to mean object with a then method, which we will try to treat as
From: Andreas Rossberg [rossb...@google.com]
Mark, could you summarize the rationale for this, or provide a more specific
link to the appropriate bit of the discussion you are referring to?
I'm not Mark, and he might have something more specific in mind, but this
summary was pretty helpful:
401 - 500 of 649 matches
Mail list logo
