I've been answering quite a few questions about promises on stack overflow
lately. One of the key things people seem to struggle to get their head around
is the idea of `.then` as being something that transforms the promise and
returns a new promise. They either expect it to mutate the
Stating `then()` is something more advanced than `done()` doesn't make much
sense to me.
They're different methods, that serve different purpose, I think they should
be valued on a similar level.
Key thing is that *`then()` is conceptually a `map()`*, and there's
something wrong if just to access
I would think the advantage of running compile-time checks against the
global object is that it can catch errors that we currently use linters for:
// OOPS - forgot this line!
// import { x } from foo;
function someRareCase() {
x(); // Reference error?
}
That's useful,
On Thu, Jun 20, 2013 at 9:55 AM, Kevin Smith zenpars...@gmail.com wrote:
I would think the advantage of running compile-time checks against the
global object is that it can catch errors that we currently use linters for:
// OOPS - forgot this line!
// import { x } from foo;
This actually is the sort of thing that can be difficult to check for
off-line linters, because the use of global variables may depend on
some staged dynamic configuration that a linter cannot easily see,
verify, or assume.
That's pretty much true for everything about javascript : )
In my
We think static checking for unbound variables is valuable, and
letting people write `console.log` without having to import anything
is valuable. Thus, option 3.
I think that's fine, if we're willing to discourage dynamic usage of the
global object for unbound variables. Static checking of
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise = function() { ... }
// main.js
import polyfillz.js;
new Promise();
This would refuse to compile, right? We'd have to introduce all of our
Le 20/06/2013 14:55, Forbes Lindesay a écrit :
I've been answering quite a few questions about promises on stack
overflow lately.
Do you have a link to a list to these questions (and/or your answers)
off-top your browser history by any chance?
One of the key things people seem to struggle
The loader hooks are fantastic. In the case of translate(), consider:
module Button from classes/ui/Button.js
module Button from classes/ui/Button.dart
module Button from classes/ui/Button.ts
module Button from classes/ui/Button.coffee
module Button from classes/ui/Button.zip
module Button
Brendan Eich wrote:
out of date quickly, besides not being attractive to developers who
cannot count on it exception in brand X.
except in brand X, of course.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Jonathan Bond-Caron wrote:
If translate() is intended as a hook for transpilation, it will lead to
fragmentation.
This does not make sense, because no would-be-fragmenter (browser brand
X) gains share by shipping pre-packaged translators -- they'd be
implemented in JS and managed on github,
On Thu, Jun 20, 2013 at 7:50 AM, David Bruant bruan...@gmail.com wrote:
Le 20/06/2013 14:55, Forbes Lindesay a écrit :
I’ve been answering quite a few questions about promises on stack
overflow lately.
Do you have a link to a list to these questions (and/or your answers)
off-top your
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote:
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise = function() { ... }
// main.js
import polyfillz.js;
new
Do you have a link to a list to these questions?
Here are a few examples:
- [how to make-sequential rest webservices calls with
angularjs](http://stackoverflow.com/questions/16854963/how-to-make-sequentially-rest-webservices-calls-with-angularjs/16856156)
- [Why does my Q chained promise
Yes, like so:
script src=polyfillz.js/
Sure. In a server environment, you'd have to do your monkey-patching and
then load your main module dynamically through the loader api.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
I'm worried that you may be suffering from and spreading a terminology
confusion. Promise pipelining is an important latency reduction
optimization when using promises over a network. See Chapter 16 of
http://erights.org/talks/thesis/markm-thesis.pdf. Using .then, either
with or without the
2013/6/20 David Bruant bruan...@gmail.com
I wasn't there when that started, but it feels like then organically
grew out of the experience of using promises a lot which naturally leads to
promise pipelining.
Terminology nit: if by promise pipelining you mean the fact that p.then()
returns a
Sorry for the noise. I didn't see Mark's reply while offline.
2013/6/20 Tom Van Cutsem tomvc...@gmail.com
2013/6/20 David Bruant bruan...@gmail.com
I wasn't there when that started, but it feels like then organically
grew out of the experience of using promises a lot which naturally leads
On 1 June 2013 20:52, Jorge jo...@jorgechamorro.com wrote:
On 02/06/2013, at 01:22, Brandon Benvie wrote:
On 6/1/2013 3:44 PM, Jorge wrote:
{
block: {
if (true) {
break block;
}
}
}
But then... I'm not sure this is any better than an IIFE!
Anything is better than
Le 20/06/2013 18:08, Mark Miller a écrit :
On Thu, Jun 20, 2013 at 7:50 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 20/06/2013 14:55, Forbes Lindesay a écrit :
I’ve been answering quite a few questions about promises on stack
overflow lately.
Naively translating the standard pipeline example gives
x.a().then( t1=
y.b().then( t2=
t1.c(t2).then( t3=
... ) ) )
..
This is naïve because the synchronous method calls should really
be asynchronous message sends. If we assume local proxies that
forward local method calls to remote
Returning to Mark Miller's comment:
Any beginning JavaScript programmer learns the meaning of `a.foo(b,c)`, i.e.,
synchronous message send, long before they learn about callbacks.
I don't see any simple and obvious path from understanding the synchronous
message send to understanding how
On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith zenpars...@gmail.com wrote:
I wonder, though, if this might create issues for polyfilling:
// polyfillz.js
if (this.Promise === void 0)
this.Promise =
Hi, sorry if this is tangentially related to the conversation, however I've
just got a simple question. How would you call eval() with the ThisBinding
inside the evaluated code being a custom item? In ES5 we'd do something
like the following:
(function () {
eval(foo);
}).call(bar);
24 matches
Mail list logo
