Re: Future cancellation
On Tue, Apr 30, 2013 at 7:26 AM, Brendan Eich bren...@mozilla.com wrote:
Lucas Smith wrote
IMO, cancelation is not appropriate for promises/futures. (sticking with
the name promises, sorry for the distraction).
Agreed.
Glad to see everyone agreeing on something about promises for a
change. Unfortunately, I think you're all wrong. ^_^
Every future is cancellable already. If you hand out your resolver,
anyone with it can preempt you and (prematurely?) fulfill the promise,
before your intended code-path finishes. There are only two small
differences between normal promises and ones that are explicitly
cancellable:
1. Some promises are holding onto resources (locks, network
connections, cpu time) which will be disposed of when they're
finished. If you want to allow someone else to pre-empt you, you need
to be able to release these resources when that happens, so you're not
spinning your wheels doing work only to make a useless
resolver.accept(dead-value) that just gets ignored because the
promise is already fulfilled. So, the constructor for the promise
needs some way to register some teardown code, called when the promise
is fulfilled.
2. The default case for cancellable promises is that they want their
promise consumers to be able to cancel them, as opposed to normal
promises that usually want to maintain complete control over their
fulfillment. So, you probably want to return something with resolving
powers by default, in addition to the promise itself.
I think this is more than acceptable for a subclass, and I think it's
quite simple to do:
1. the constructor should take a second callback, which is called with
no arguments when the promise is fulfilled by any mechanism, and which
is intended for teardown code. It has no effect on the promise's
state.
2. The return value of the constructor should be a {promise, resolver}
pair, rather than just the promise itself. This maintains the
separation of capabilities, but lets the consumer kill the promise if
they don't need it anymore.
This design adds minimal new surface area, solves the necessary
problems, and lets consumers either accept or reject the promise when
they cancel it, so they can provide a default value to other
consumers transparently.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Tue, Apr 30, 2013 at 10:01 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I think the .NET disposal analogy is a good one. I don’t know how other
runtimes handle it, but in .NET you would dispose of a resource (perhaps
representing an in-progress asynchronous operation) by having the handle for
that resource implement IDisposable, i.e. have a dispose() method. So I
think if you wanted to do something similar with promises, you’d return a
disposable handle alongside your promise (i.e. `return { promise, diposable
}` or simply `{ promise, dispose }`). You can also layer that on top of the
promise (i.e. `promise.dispose = () = { .. }; return promise;`).
I don't see how the layer on top solution is different from
subclassing? In both cases you get an object which implements the
Future interface and additionally has a .cancel()/.dispose() method on
it. The only difference appears to be the name?
I don't really see the benefit of returning a { promise, dispose }
tuple as result comparsed to the layering/subclassing solution.
With the tuple approach, you get two objects one which represents the
operation and one which represents the result. The result object can
be composed with other promises or you simply register to wait for the
result. So something like:
{ promise, dispose } = doSomeOperation();
handleResult(promise);
cancelIfUserClicksAbort(dispose);
or
{ promise, dispose } = doSomeOperation();
cancelIfUserClicksAbort(dispose);
return promise;
or
{ promise, dispose } = doSomeOperation();
cancelIfUserClicksAbort(dispose);
promise.then(val = displayResult(val));
with the layering/subclassing approach you do essentially exactly the
same thing, except you use a single object rather than two:
cancelableFuture = doSomeOperation();
handleResult(cancelableFuture);
cancelIfUserClicksAbort(cancelableFuture);
or
cancelableFuture = doSomeOperation();
cancelIfUserClicksAbort(cancelableFuture);
return cancelableFuture;
or
cancelableFuture = doSomeOperation();
cancelIfUserClicksAbort(cancelableFuture);
cancelableFuture.then(val = displayResult(val));
However with this approach you get an API which automatically simply
works as an API returning a Future in case you don't need to abort the
operation or display its progress:
handleResult(doSomeOperation());
or
return doSomeOperation();
or
doSomeOperation().then(val = displayResult(val));
I.e. if you don't care about the operation part, the API simply works
as any other API which returns a promise. This seems like a very nice
thing. The only cost of this API is that it doesn't compose when you
compose the future, but neither does the dispose object in the tuple
approach.
/ Jonas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
Hi Ron,
Thanks for engaging and not being put off by my previous message. I
understand it could have come across as rather abrasive. Apologies for
that. More inline.
On Tuesday, April 30, 2013, Ron Buckton wrote:
Alex,
** **
Thank you for the feedback. I’ve also added two more gists:
** **
4. Cancellation using CancellationTokenSource: *
https://gist.github.com/rbuckton/5490373*https://gist.github.com/rbuckton/5490373
This is interesting. Is there a reason to allow configuration of the
cancelation token? I had thought the value in having a standard mechanism
(and value for this future was canceled) would be to avoid per-API
contracts of the sort that might be created here.
Also, if it's really necessary but turns out to be rare, we might imagine
Future/Resolver subclass pairs that are pre-configured with different
cancel values instead of configuration. But I don't have experience with
how common cancelation through chains of Futures with different cancelation
roots is.
5. Cancellation using CancelableFuture subclass: *
https://gist.github.com/rbuckton/5490482*https://gist.github.com/rbuckton/5490482
This design is roughly what I'd sketched out for Anne van Kesteren as what
DOM will need to do for XHR as it already vends the cancelation capability
there.
Our designs for this diverged in that I hadn't overridden then/catch to
enable chaining, instead relying on the cancel error value in rejection.
Each one of these is an attempt to find out exactly what does and
doesn’t work with various mechanisms for cancellation that have been
discussed on these lists as well as in various libraries.
** **
In [1] I added the synchronous flag as a way to ensure that the Future
that is used for cancellation can resolve and have its resolve callbacks
run in time. It’s not exactly necessary but there are some cases where not
being able to cancel synchronously could bite a developer:
** **
function someAsync(cancelFuture) {
return new Future(function (resolver) {
var handle = setImmediate(function () { … });
cancelFuture.done(function () { clearImmediate(handle); });
});
}
** **
var { token, cancel } = createCanceler();
var f = someAsync(token);
cancel();
** **
Due to asynchronous resolution, even though cancel() is called
synchronously it will be scheduled **after** the setImmediate call.
**
This honestly feels like a separate side contract about what it means to
cancel some underlying operation, not what it means to get the resolution
value...and it feels like the sort of thing that cancelable futures need to
navigate with regards to the semantics of the underlying operation that
they're representing. Put another way, it's about what resolvers say to
resolvers and when. ISTM that any future subclass should be able to
schedule synchronous resolution for cancel if it wants to. I don't think
that breaks any invariants of the design. The question now is where that
belongs. Punning too strongly on the superclass resolution semantics feels
wrong, but so does carving out brand new API space for synchronous
resolution until we have at least one more use-case for it. For now, we
could simply say that CancelableFuture cancels synchronously and leave that
up to impls to accomodate. Feels dirty, but preserves the ability to
explain it later with a synchronous flag should we find it more broadly
necessary.
**
[2] was based on a side discussion around cancellation and similarities to
revocable Proxies.
** **
[3] was based on providing a simple means of cancellation, but I agree
that there is a danger that a Future that is referenced by multiple
consumers could be canceled by any consumer.
** **
[4] is inspired by cooperative cancellation of Tasks in .NET. I’ve used
this quite often and found it to be a powerful cancellation mechanism. It
has the advantage of being very explicit about where responsibilities lie
as part of cancellation and reducing pollution of the Future API, but it
does add additional complexity around setup. I’m personally in favor of
this approach, though not so fond of the name of types. [1] is partially
based on this approach as well, except that CTS cancels synchronously and
can automatically reject a Future.
** **
[5] is a possible approach (albeit a naïve implementation) of cancellation
via a subclass. In its current incarnation it suffers from the same issues
a [1] and [2], but can be mitigated by having it directly call the
resolver’s resolve algorithm with the synchronous flag set. It also gets
lost when using Future.any, etc.
** **
My intent currently is not to advocate any of these approaches. Rather;
I’m trying to catalogue each approach as I’ve come across them specifically
to gather this kind of feedback.
Much appreciated. I've fretted for some time that I've under-researched the
cancellation
Re: Future cancellation
On Wednesday, May 1, 2013, Jonas Sicking wrote: On Mon, Apr 29, 2013 at 6:57 PM, Ron Buckton rbuck...@chronicles.orgjavascript:; wrote: I’ve created separate gists for three different ways that I am currently investigating as a means to support the cancellation of a Future. These can be found here: 1. Cancellation using Future: https://gist.github.com/rbuckton/5486149 2. Cancellation using Future.cancelable: https://gist.github.com/rbuckton/5484591 3. Cancellation using Future#cancel: https://gist.github.com/rbuckton/5484478 Each has a list of some of the benefits and issues I’ve seen while experimenting with each approach, as well as possible changes to the various APIs or algorithms for Future to make each happen. In general, cancellation of a Future can be beneficial in a number of cases. One example is the case where you are requesting a resource from a remote server using XHR. If the request was being made to fetch a page of data, and the user opted to move to the next page before the current page completed loading, it no longer becomes necessary to continue fetching the remote resource. In addition, it is no longer necessary to handle any additional computation or transformation logic that would have resulted from the successful completion of the fetch operation. Having the ability to cancel the request allows an application to quickly release resources that it no longer needs. It is also useful to be able to handle the cancelation of a long running task that might be executing in a Worker. In this case, cleanup logic that is part of cancelation would request the worker to close, ending the current operation and releasing resources. Both of the above examples are indicative of cancelling the root of an operation, but there are also circumstances where you might want to cancel a chained Future and any Future chained from it, without canceling the root. In the previous example regarding paged data, I might wish to allow the fetch operation to complete so that I could cache the data for quick retrieval, but would only want to cancel any possible UI updates that might occur in a chained Future. I’m interested to hear what others think with respect to properly handling cancellation with Futures. I do not think that we should add cancellation on the base Future interface. I.e. we shouldn't make *all* Futures cancellable. Cancelability should only be possible when the implementation of the Future would actually stop doing work if the Future is cancelled. I.e. cancelling a Future shouldn't simply prevent the result callbacks from being called, but it should prevent whatever work is needed to calculate the result from happening. However it would be very complex and expensive if we had to make all APIs that want to use Futures also support being cancelled. The solution is to create a subclass of Future which allows the back-end work to be cancelled. I.e. a CancelableFuture, or AbortableFuture. This subclass would have a .cancel() or .abort() method on it. The FutureResolver created when the CancelableFuture is created would have a callback which is called when .cancel()/.abort() is called. This is what I've sketched in various places, including for Anne WRT XHR. I suppose (without any cause) that folks would pick up on the idea that the minimal Future superclass was being explicitly designed to be subclassable to address issues like this and progress notification. Perhaps we need to call it out more explicitly in the spec? This would be useful if we create an Future-based API for doing network requests or file reading. In other words, the should be the choice of the implementor of a given API to determine if it wants to return a Future which can be cancelled, or one that can't. Obviously this needs to be documented for that API, just like you document that the API returns a Future at all. / Jonas ___ es-discuss mailing list es-discuss@mozilla.org javascript:; https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 10:45 AM, Alex Russell slightly...@google.com wrote: This is what I've sketched in various places, including for Anne WRT XHR. I suppose (without any cause) that folks would pick up on the idea that the minimal Future superclass was being explicitly designed to be subclassable to address issues like this and progress notification. Perhaps we need to call it out more explicitly in the spec? The specification does need to address that better, in particular what then() and catch() might return for subclassed futures. We found use cases both for returning a new instance of the subclassed future itself (ProgressFuture) and simply returning a new base future (for the crypto APIs). I think we want to define some of the common ones directly in the specification. That will a) help people designing their own and b) encourage some level of consistency. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
[General comments here, specifics inline.] My experiences with promises is as an E programmer. When they are used pervasively in an application the graph can get as messy as the reference graph of an object oriented program. For languages with objects and references, garbage collection became the generally accepted way of cleaning up the mess (c.f. C++). For promises, breaking the promise allows the graph to be cleaned up. On 4/30/13 at 11:04 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Every future is cancellable already. If you hand out your resolver, anyone with it can preempt you and (prematurely?) fulfill the promise, before your intended code-path finishes. There are only two small differences between normal promises and ones that are explicitly cancellable: This comment seems to be the essence of the issue. You can hold the resolver at the edge of a abortable computation. When you decide to abort the computation, perhaps because one or more consumers have indicated they are no longer interested in the results, you can use the resolver to resolve the promise as broken. That broken promise will filter up through all computations which depend on it's value, allowing them to proceed knowing that the value will not be produced. 1. Some promises are holding onto resources (locks, network connections, cpu time) which will be disposed of when they're finished. I think this statement is wrong. Promises don't hold resources. They are a placeholder for a value to be provided later. Perhaps the computation which may provide the value at some future time holds a resource, or the computation which will consume the value when it is resolved holds a resource (generally a poor programming practice), but the promise itself doesn't hold resources. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
The specification does need to address that better, in particular what
then() and catch() might return for subclassed futures. We found use
cases both for returning a new instance of the subclassed future
itself (ProgressFuture) and simply returning a new base future (for
the crypto APIs).
I think this difficulty points to a deeper issue with attempting to make a
promise something other than a placeholder for a value. Namely: it's no
longer obvious how the information or abilities stored in the promise
itself should propagate through the graph. The featureless-ness of
promises is one of their most important features.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
Some brief, general observations:
- Dave, your argument that URI's as a naming mechanism is a failure
cherry-picks cases where URIs were obviously overkill. You have not shown
that URIs are overkill in this situation. In order to do so, you would
need to posit a centralized naming authority, or a dependency management
system (e.g. package manager) with attendant dependency metadata. Or else
you would need to show that for any reasonable selected subgraph of the
global module (really package) graph, the chance of name collision is
near-zero.
- To repeat my last argument, the module URL resolution semantics proposed
in this design (that strings such as jquery are resolved relative to some
base URL, and that a .js extension is added), can be coded in about 10
lines, by my guess. Are we seriously to accept these sloppy semantics
should be the default for the web, for all time? How is that anything but
a non-starter, given that it conflicts with all other resolution semantics
on the web?
- It seems that every response to Andreas comes with a new requirement for
modules that we have not yet seen on es-discuss. How can we possibly have
a meaningful discussion of a solution when we don't even know what the
goals are? Can someone provide a list of the requirements?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
2013/5/1 Anne van Kesteren ann...@annevk.nl
On Wed, May 1, 2013 at 10:45 AM, Alex Russell slightly...@google.com
wrote:
This is what I've sketched in various places, including for Anne WRT
XHR. I
suppose (without any cause) that folks would pick up on the idea that the
minimal Future superclass was being explicitly designed to be
subclassable
to address issues like this and progress notification. Perhaps we need to
call it out more explicitly in the spec?
The specification does need to address that better, in particular what
then() and catch() might return for subclassed futures. We found use
cases both for returning a new instance of the subclassed future
itself (ProgressFuture) and simply returning a new base future (for
the crypto APIs).
For YUI we tried something like:
then(callback, errback) {
return new this.constructor(function (resolver) {
// ...
});
}
While it is true that there are use cases for both, there are use cases
that get broken when returning a instance of the subclass. For example, a
LazyPromise which runs the initialization function only when then() is
called, breaks down with this approach. It seems to me that if some use
cases break and for others the same effect can be achieved using a
different approach, then the safest path should be taken. That seems to be
only returning base promises from then().
2013/5/1 Kevin Smith zenpars...@gmail.com
I think this difficulty points to a deeper issue with attempting to make a
promise something other than a placeholder for a value.
The fact is that in a way promises are already a representation for a value
and for an operation. What is a promise for undefined? Let's say I have a
database object with a close() method that works asyncronously. If close()
returns a promise, which value does it represent?
As for cancellation, I worry about the ergonomics of returning { promise,
cancel } pairs. Like Alex mentioned, a subclass makes a lot more sense for
XMLHttpRequest. And if it works for XHR why shouldn't it work for other
promises?
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 5:50 AM, Bill Frantz fra...@pwpconsult.com wrote: On 4/30/13 at 11:04 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Every future is cancellable already. If you hand out your resolver, anyone with it can preempt you and (prematurely?) fulfill the promise, before your intended code-path finishes. There are only two small differences between normal promises and ones that are explicitly cancellable: This comment seems to be the essence of the issue. You can hold the resolver at the edge of a abortable computation. When you decide to abort the computation, perhaps because one or more consumers have indicated they are no longer interested in the results, you can use the resolver to resolve the promise as broken. That broken promise will filter up through all computations which depend on it's value, allowing them to proceed knowing that the value will not be produced. I think it's reasonably valuable to allow cancelers to choose whether to cancel the computation with an error, or to cancel it with another value. For example, you could race an XHR promise and a timeout promise, and if the timeout finishes first, it cancels the XHR with a default value. (Hm, on the other hand, this use-case is already taken care of by Future.any(), especially if we spec that Future.any() auto-cancels any cancellable futures passed to it if they don't resolve in time.) 1. Some promises are holding onto resources (locks, network connections, cpu time) which will be disposed of when they're finished. I think this statement is wrong. Promises don't hold resources. They are a placeholder for a value to be provided later. Perhaps the computation which may provide the value at some future time holds a resource, or the computation which will consume the value when it is resolved holds a resource (generally a poor programming practice), but the promise itself doesn't hold resources. Semantics. ^_^ The promise can represent a computation, which can hold some releasable resources. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
* Jonas Sicking wrote: Then there's of course the issue of what we should do with APIs that combine several Futures into a single one. Like Future.every() etc. Similarly, there's also the issue of what to do with chaining. I'm tempted to say that if you create combined or dependent Futures, you still only have the ability to cancel them through the original CancelableFuture. And the progress of multiple Futures can only be observed through the individual ProgressFuture objects? I would expect the opposite. Similarily, I would expect to be able to mix ProgressFuture objects with other Future objects, and still be able to observe progress of the combination. And if I can do that, I would also expect that I can turn a single Future into a ProgressFuture in this sense, but then the whole subclassing idea kinda breaks down, why bother with that. And cancelation does not seem quite so different from pro- gress in this sense. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking jo...@sicking.cc wrote: However with this approach you get an API which automatically simply works as an API returning a Future in case you don't need to abort the operation or display its progress: handleResult(doSomeOperation()); or return doSomeOperation(); or doSomeOperation().then(val = displayResult(val)); I.e. if you don't care about the operation part, the API simply works as any other API which returns a promise. This seems like a very nice thing. The only cost of this API is that it doesn't compose when you compose the future, but neither does the dispose object in the tuple approach. The other cost is an inherent capability leak - *unless* you purposely strip it of its cancelability, passing it around to anything else gives the anything else the ability to cancel your promise as well. The tuple approach doesn't have this issue - the promise and the canceler/resolver are inherently separated, and you have to purposely hand the canceler/resolver off to other code for it to have any powers. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Wed, May 1, 2013 at 7:18 AM, Kevin Smith zenpars...@gmail.com wrote: - Dave, your argument that URI's as a naming mechanism is a failure cherry-picks cases where URIs were obviously overkill. You have not shown that URIs are overkill in this situation. In order to do so, you would need to posit a centralized naming authority, or a dependency management system (e.g. package manager) with attendant dependency metadata. Or else you would need to show that for any reasonable selected subgraph of the global module (really package) graph, the chance of name collision is near-zero. Or, we can simply point to real-world examples of large-scale custom namespaces, where there is no central authority, the chance of collision is very low and can be largely predicted and worked around ahead of time, and in the case of collisions, the author can manually work around the issue without too much difficulty. See: jQuery modules, python modules, and many others. Some of these *have* a central distribution authority which prevents name conflicts for people using it, but it's optional to use. Central naming authorities are only necessary if you need complete machine-verifiable consistency without collisions. As long as humans are in the loop, they tend to do a pretty good job of avoiding collisions, and managing them when they do happen. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: HTML date format and Date.parse()
On Tue, Apr 30, 2013 at 4:34 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Or maybe we should both just stick to a valid subset of ISO 8601. Do you mean: achieve consistency by having HTML retract its extensions to ISO 8601? I'm pretty sure that ship has sailed. Strictly speaking, so has ES55/5.1's date format. There's a difference, though, between adding and removing functionality. Adding support for spaces in 15.9.1.15 is backward-compatible. Removing support for spaces from HTML, as you propose, wouldn't be. ES6 annex B is the appropriate place to define browser host web reality extensions to Date.parse. I'm proposing a one-line change to 15.9.1.15 (allow a space in place of 'T') and an equally minor change to 15.9.1.15.1 (extended years), plus a sentence or two of rationale. The proposal has nothing to do with the unspecified legacy formats. I agree it'd be nice to get the intersection of those formats documented, but it's a tangent. For that reason, it would probably be better to define static methods for parsing specific formats. For example, Date.parseHTMLDate(str) //only recognizes whatever HTML defines The reason I propose changing 15.9.1.15 is to have one *less* thing to remember. To unify, since we actually have an opportunity to do that here, for once! Why is it important to have Date.parse(2013-01-01 10:30Z) return NaN? -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: HTML date format and Date.parse()
On Wed, May 1, 2013 at 4:45 PM, Jason Orendorff jason.orendo...@gmail.com wrote: The reason I propose changing 15.9.1.15 is to have one *less* thing to remember. To unify, since we actually have an opportunity to do that here, for once! Hear hear! -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Do futures represent a pipeline? (was Re: Future cancellation)
On Tue, Apr 30, 2013 at 12:49 PM, Kevin Gadd kevin.g...@gmail.com wrote: Thanks, the idea that .then() returns a new Promise is very very strange to me. What gets stored into that promise? Yes, promises can be through of as pipelines. The return value of .then() is a *new promise*, which gains its value from the .then() callbacks - if the callbacks return a value, it accepts/resolves with the same value; if they throw, it rejects with the error. The reasoning behind promises/futures is explained in more detail in my blog posts http://www.xanthir.com/b4PY0 http://www.xanthir.com/b4P_0 and Domenic's http://domenic.me/2012/10/14/youre-missing-the-point-of-promises/. I think I see a lot of the historical confusion here as being rooted in the fact that the terms 'promise' and 'future' seem poorly-suited for describing a pipeline oriented primitive, if that's what these futures are. Maybe all discussion threads on futures need a big hairy disclaimer that tells people to read a description of what 'future' and 'promise' actually mean in this context :) I think future is a pretty good name, personally - it means that the callbacks will be run in the future. ^_^ But promise also kinda works, and it's more common. But DOMFuture definitely needs more explanatory text (which I've promised to submit a pull request to provide...). ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise/Future: asynchrony in 'then'
On Wed, May 1, 2013 at 9:07 AM, Alex Russell slightly...@google.com wrote: On Wednesday, May 1, 2013, Tab Atkins Jr. wrote: On Tue, Apr 30, 2013 at 9:43 AM, Claus Reinke claus.rei...@talk21.com wrote: The promises-aplus spec has a note that confuses me https://github.com/promises-aplus/promises-spec#notes 1. In practical terms, an implementation must use a mechanism such as setTimeout, setImmediate, or process.nextTick to ensure that onFulfilled and onRejected are not invoked in the same turn of theevent loop as the call to then to which they are passed. I have not yet been able to decide whether DOMFuture has a similar provision, or how this note is meant to be interpreted. Juan already pointed out the queue a task language, so this is answered. This is far too glib. The spec may very well be wrong on this point. The design goal isn't to require a full yeild of the event loop, but instead to force async code flow -- that means that resolving and calling back should be able to happen at end of microtask; the same timing as Object.observe() callbacks. Possibly true, but those are details. The context of my response was someone asking about whether DOMFutures described asynchrony *at all*. The spec does mandate asynchrony, even if it might be the wrong kind of asynchrony. ^_^ ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise/Future: asynchrony in 'then'
Juan already pointed out the queue a task language, so this is answered. This is far too glib. The spec may very well be wrong on this point. The design goal isn't to require a full yeild of the event loop, but instead to force async code flow -- that means that resolving and calling back should be able to happen at end of microtask; the same timing as Object.observe() callbacks. Promises/A says has an open issue on whether callback handlers should be put on the event queue or executed immediately. Promises/A+ Promises/B both specify that callbacks may not be invoked in the same turn of the event loop. According to the harmony:observe doc, it was suggested that Schedule change events to be delivered asynchronously “at the end of the turn”. 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 occur. -s ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise/Future: asynchrony in 'then'
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 occur. We need to figure out what invariants we are enforcing, and codify them with code samples and tests. Then we can figure out the best way to specify that with words; whether the exact mechanism is microtasks or macrotasks doesn't matter, as long as the invariants are preserved. So far we have three example invariants in Promises/A+ land; more welcome: https://github.com/promises-aplus/promises-spec/pull/104#issuecomment-17290173 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On May 1, 2013 8:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking jo...@sicking.cc wrote: However with this approach you get an API which automatically simply works as an API returning a Future in case you don't need to abort the operation or display its progress: handleResult(doSomeOperation()); or return doSomeOperation(); or doSomeOperation().then(val = displayResult(val)); I.e. if you don't care about the operation part, the API simply works as any other API which returns a promise. This seems like a very nice thing. The only cost of this API is that it doesn't compose when you compose the future, but neither does the dispose object in the tuple approach. The other cost is an inherent capability leak - *unless* you purposely strip it of its cancelability, passing it around to anything else gives the anything else the ability to cancel your promise as well. The tuple approach doesn't have this issue - the promise and the canceler/resolver are inherently separated, and you have to purposely hand the canceler/resolver off to other code for it to have any powers. This is a problem that the current XHR API is suffering from too. Has that been a problem in reality? With XHR you can even affect the values that other consumers are receiving by setting .response type. Again, does anyone have examples of when this has been a problem? I feel like attempting to solve this problem will mean that we need to split a lot of interfaces into lists of objects, each representing a capability. This seems like it will very quickly lead to an unmanageable mess. Wrapping a CancelableFuture in a normal Future seems like an acceptable solution which only adds complexity in the much more rare case that someone cares about capabilities. / Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Do futures represent a pipeline? (was Re: Future cancellation)
On Wed, May 1, 2013 at 9:13 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The reasoning behind promises/futures is explained in more detail in my blog posts A while back, I also wrote up an explanation of promises starting from base principles. https://github.com/kriskowal/q/blob/master/design/README.js Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 9:38 AM, Jonas Sicking jo...@sicking.cc wrote: On May 1, 2013 8:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking jo...@sicking.cc wrote: However with this approach you get an API which automatically simply works as an API returning a Future in case you don't need to abort the operation or display its progress: handleResult(doSomeOperation()); or return doSomeOperation(); or doSomeOperation().then(val = displayResult(val)); I.e. if you don't care about the operation part, the API simply works as any other API which returns a promise. This seems like a very nice thing. The only cost of this API is that it doesn't compose when you compose the future, but neither does the dispose object in the tuple approach. The other cost is an inherent capability leak - *unless* you purposely strip it of its cancelability, passing it around to anything else gives the anything else the ability to cancel your promise as well. The tuple approach doesn't have this issue - the promise and the canceler/resolver are inherently separated, and you have to purposely hand the canceler/resolver off to other code for it to have any powers. This is a problem that the current XHR API is suffering from too. Has that been a problem in reality? With XHR you can even affect the values that other consumers are receiving by setting .response type. Again, does anyone have examples of when this has been a problem? I feel like attempting to solve this problem will mean that we need to split a lot of interfaces into lists of objects, each representing a capability. This seems like it will very quickly lead to an unmanageable mess. I don't think this is a valid slippery-slope argument. If it were true, it would show itself more strongly, as us, for example, splitting up the resolver into two or three different objects for each of the operations, and maybe the promise into two objects as well for each of the channels. In practice, you can split things into capabilities that are reasonable to group together. However, a cancellable promise blurs the line. Maybe that's not important? I dunno. Wrapping a CancelableFuture in a normal Future seems like an acceptable solution which only adds complexity in the much more rare case that someone cares about capabilities. If we knew that chaining a CancelableFuture always returned a normal Future, then this might be okay - just do getCancellableFuture(foo).then() to get a normal future out. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 11:04 AM, Bill Frantz fra...@pwpconsult.com wrote: On 5/1/13 at 7:54 AM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: On Wed, May 1, 2013 at 5:50 AM, Bill Frantz fra...@pwpconsult.com wrote: On 4/30/13 at 11:04 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: ... 1. Some promises are holding onto resources (locks, network connections, cpu time) which will be disposed of when they're finished. I think this statement is wrong. Promises don't hold resources. They are a placeholder for a value to be provided later. Perhaps the computation which may provide the value at some future time holds a resource, or the computation which will consume the value when it is resolved holds a resource (generally a poor programming practice), but the promise itself doesn't hold resources. Semantics. ^_^ The promise can represent a computation, which can hold some releasable resources. To my mind this is an important distinction. The promise does not represent the computation. It represents the result. Any representation of the computation itself bring in a whole lot baggage which includes, the problem of managing distributed computation in the cloud plus a lot of other issues. Dragging this stuff into the base level of a programming language is a bad crossing of abstraction levels. I think you're making this far too complicated. It's much simpler than this: 1. XHR is a very reasonable API to Future-ize. 2. XHRs are cancellable. 3. Ergo, we should have a cancellable Future subtype. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
I think you're making this far too complicated. It's much simpler than
this:
1. XHR is a very reasonable API to Future-ize.
2. XHRs are cancellable.
3. Ergo, we should have a cancellable Future subtype.
Curious: has this proposed XHR api been published anywhere?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 11:17 AM, Kevin Smith zenpars...@gmail.com wrote: I think you're making this far too complicated. It's much simpler than this: 1. XHR is a very reasonable API to Future-ize. 2. XHRs are cancellable. 3. Ergo, we should have a cancellable Future subtype. Curious: has this proposed XHR api been published anywhere? I thought it was at https://github.com/slightlyoff/DOMFuture, but looks like it doesn't include an XHR example reworking yet. For an example, though, just look at something like jQuery's API, but with the callback arguments moved to a returned future. (Or jQuery's deferred-based API.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Future cancellation
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 };
}
function getUser3() {
return doXHR(/user.json).then(function (user) {
user.metadata = meta tags are old school;
});
}
```
Here, `getUser1()` returns a cancellable promise, but `getUser2()` does not,
even though they should have the same semantics. Worse, `getUser3()` isn't
cancellable, even though it was originally derived from an XHR. Trying to fix
the `getUser3()` case is what takes you down the slope of complex additional
semantics.
Much better would be if a hypothetical future XHR utility returned a `{
promise, abort }` object, with no logical connection between the `abort` and
the `promise` (besides maybe rejecting the promise with a well-known error).
This seems much better than trying to make a general cancellation concept for
promises and overloading them with additional semantics about the operation
being performed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Do futures represent a pipeline? (was Re: Future cancellation)
There's also an extensive set of citations and links at the bottom of http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#see. On Wed, May 1, 2013 at 9:54 AM, Kris Kowal kris.ko...@cixar.com wrote: On Wed, May 1, 2013 at 9:13 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The reasoning behind promises/futures is explained in more detail in my blog posts A while back, I also wrote up an explanation of promises starting from base principles. https://github.com/kriskowal/q/blob/master/design/README.js Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Future cancellation
This is where something like an external cancellation source could be more
effective:
```js
function getUser1(cancelToken) {
return doXHR(/user.json, cancelToken);
}
function getUser2(cancelToken) {
// immediate result, no need for cancellation
return { name: domenic };
}
function getUser3(cancelToken) {
return doXHR(/user.json, cancelToken).then(function (user) {
user.metadata = meta tags are old school;
});
}
var cts = new CancellationTokenSource();
var usersF = Future.every(getUser1(cts.token), getUser2(cts.token),
getUser3(cts.token));
usersF.done(function(users) {
});
cts.cancelAfter(5000); // timeout after 5 seconds.
```
Rather than subclassing Future, you use an external source provided by the
caller to manage cancellation. Now it doesn't matter whether either of the 3
methods have a return value that supports cancellation, and if the caller
doesn't need to cancel, it can provide null or undefined.
Ron
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Domenic Denicola
Sent: Wednesday, May 1, 2013 11:23 AM
To: Tab Atkins Jr.; Bill Frantz
Cc: public-script-co...@w3.org; Brendan Eich; es-discuss
Subject: RE: Future cancellation
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 };
}
function getUser3() {
return doXHR(/user.json).then(function (user) {
user.metadata = meta tags are old school;
});
}
```
Here, `getUser1()` returns a cancellable promise, but `getUser2()` does not,
even though they should have the same semantics. Worse, `getUser3()` isn't
cancellable, even though it was originally derived from an XHR. Trying to fix
the `getUser3()` case is what takes you down the slope of complex additional
semantics.
Much better would be if a hypothetical future XHR utility returned a `{
promise, abort }` object, with no logical connection between the `abort` and
the `promise` (besides maybe rejecting the promise with a well-known
error). This seems much better than trying to make a general cancellation
concept for promises and overloading them with additional semantics about
the operation being performed.
___
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: Module naming and declarations
On Wed, May 1, 2013 at 8:28 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Central naming authorities are only necessary if you need complete machine-verifiable consistency without collisions. As long as humans are in the loop, they tend to do a pretty good job of avoiding collisions, and managing them when they do happen. I would go further: because humans are involved, requiring a central naming authority, like an URL, for module IDs are a worse choice. There are subcultures that ascribe slightly different meanings to identifiers, but still want to use code that mostly fits that identifier but is from another subculture. The current approach to module IDs in ES modules allows for that fuzzy meaning very well, with resolution against any global locations occurring at dependency install/configure time, when the subculture and context is known. It would require more config, generate more friction and more typing with runtime resolution of URL IDs. Examples from the AMD module world: 1) Some projects want to use jQuery with some plugins already wired up to it. They can set up 'jquery' to be a module that imports the real jQuery and all the plugins they want, and then return that modified jQuery as the value for 'jquery'. Any third party code that asks for 'jquery' still gets a valid value for that dependency. With ES modules in their current form, they could do this without needing any Module Loader configuration, and all the modules use a short 'jquery' module ID. 2) A project developer want to use jQuery from the project's CDN. A third party module may need jQuery as a dependency, but the author of that third party module specified a specific version range that does not match the current project. However, the project developer knows it will work out fine. The human that specified the version range in that third party module did not have enough context to adequately express the version range or the URL location. The best the library author can express is I know it probably works with this version range of jQuery. If all the modules just use 'jquery' for the ID, the project developer just needs one top level, app config to point 'jquery' to the project's CDN, and it all works out. An URL ID approach, particularly when version ranges are in play, would mean much more configuration that is needed for the runtime code. All the IDs would require more typing, particularly if version ranges are to be expressed in the URLs. Summary: It is best if the suggestions on where to fetch a dependency from a globally unique location and what version range is applicable are done in separate metadata, like package.json, bower.json, component.json. But note that these are just suggestions, not requirements, and the suggestions may vary based on the project context. For example, browser-based vs. server-based, or mobile vs. desktop. Only the end consumer has enough knowledge to do the final resolution. It would be awkward to try to encode all of the version and context choices in the module IDs used for import statements as some kind of URL. Even if it was attempted, it could not be complete on its own -- end context is only known by the consumer. So it would lead to large config blocks that need to be loaded *by the runtime* to resolve the URL IDs to the actual location. With short names like 'jquery', there is a chance to just use convention based layout, which means no runtime config at all, and if there is config, a much smaller size to that config than what would be needed for URL-based IDs. Any resolution against global locations happens once, when the dependency is brought into the project, and not needed for every runtime execution. Plus less typing is needed for the module IDs in the actual JS source. In addition, the shorter names have been used successfully in real world systems, examples mentioned already on this thread, so they have been proven to scale. James ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
Thanks James, for your input. As an aside, I want to make perfectly clear
that I don't think the AMD approach to module IDs is necessary a bad thing,
or that full http URLs are necessarily any better for dependency naming.
I am arguing that AMD resolution semantics should not be baked in.
I am arguing that URLs should be the only *default* means of specifying
external modules in the browser, with standard URL semantics.
I am arguing that we should not bake *any* package dependency resolution
strategy into the core module system. Especially not something as fuzzy
as module IDs.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Most current Proxy-as-implemented test suite?
In Caja we have several uses for Proxies, some of which involve reimplementing or modifying the Proxy API. We are currently following the original harmony:proxies (rather than direct or notification proxies) since that's what is available in browsers. What is the most current test suite available for this variant of proxies? So far I have found http://hg.ecmascript.org/tests/harmony/, which seems to be a more recent version of what we are currently using, but has it been superseded by something else? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On 5/1/13 at 11:13 AM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: I think you're making this far too complicated. It's much simpler than this: 1. XHR is a very reasonable API to Future-ize. 2. XHRs are cancellable. 3. Ergo, we should have a cancellable Future subtype. Why make it more complex than necessary. While a XHR implementation may wish to add a cancel operation, JS is a broader language than just the web. There are use cases that don't need cancel and they should not have to pay the costs of the additional communication paths that cancel will require. With a simple promise, others can build objects which use the promise as an internal component and provide cancel or other useful operations. Leaving the implementations of these other operations to libraries will allow experimentation to proceed standardization. Cheers - Bill --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On Wed, May 1, 2013 at 1:29 PM, Bill Frantz fra...@pwpconsult.com wrote: On 5/1/13 at 11:13 AM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: I think you're making this far too complicated. It's much simpler than this: 1. XHR is a very reasonable API to Future-ize. 2. XHRs are cancellable. 3. Ergo, we should have a cancellable Future subtype. Why make it more complex than necessary. While a XHR implementation may wish to add a cancel operation, JS is a broader language than just the web. There are use cases that don't need cancel and they should not have to pay the costs of the additional communication paths that cancel will require. With a simple promise, others can build objects which use the promise as an internal component and provide cancel or other useful operations. Leaving the implementations of these other operations to libraries will allow experimentation to proceed standardization. Ah, I'm not proposing that we augment the base Future class with cancellation properties. I explicitly used the term subtype in the quoted bit above. *Some* of Ron's suggestions were to augment the base Future class, but not all of them, and several other people pushed back on that. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Most current Proxy-as-implemented test suite?
Le 01/05/2013 22:26, Kevin Reid a écrit : In Caja we have several uses for Proxies, some of which involve reimplementing or modifying the Proxy API. Out of curiosity, how are you modifying it? for which use case? We are currently following the original harmony:proxies (rather than direct or notification proxies) since that's what is available in browsers. Firefox implements and shipped direct proxies as part of Firefox 18 [1]. At this occasion, I moved the old proxy design MDN documentation in its own page [2]. Last I heard, V8 was waiting on the spec to stabilize before moving forward on implementation [3]. The API on the table for now is direct proxies. Notification proxies are being discussed but haven't met consensus yet (are there news on this front, TC39ers?). If anything, I would recommend to move away from the initial proxy design for Caja, because the harmony:proxies API is meant to never see light in the spec (and should probably be removed from Firefox). Among other things, harmony:proxies would have requires to ~double the memory to check ES5 invariants regarding non-extensibility and non-configurability. Direct proxies make the check on the target (and make the forwarding proxy first-class which enables optimizations that probably couldn't have been possible in the previous design). Notification proxies guarantee the invariants by design, but force a slightly different programming style. Tom Van Cutsem wrote a direct proxies shim that runs on top of current browser implementations [4]. If you want to move to direct proxies, it might be something to consider. What is the most current test suite available for this variant of proxies? So far I have found http://hg.ecmascript.org/tests/harmony/, which seems to be a more recent version of what we are currently using, but has it been superseded by something else? I have started an unofficial test suite for direct proxies [4][5]. It's incomplete, but if you want to move to direct proxies, that would be a good start I guess. Review the tests before fully trusting them, so far it's been only me working on that. David [1] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy [2] https://developer.mozilla.org/en-US/docs/JavaScript/Old_Proxy_API [3] http://code.google.com/p/v8/issues/detail?id=1543#c28 [4] https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js [5] https://github.com/DavidBruant/ProxyTests [6] http://davidbruant.github.io/ProxyTests/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Most current Proxy-as-implemented test suite?
On Wed, May 1, 2013 at 2:17 PM, David Bruant bruan...@gmail.com wrote: Le 01/05/2013 22:26, Kevin Reid a écrit : In Caja we have several uses for Proxies, some of which involve reimplementing or modifying the Proxy API. Out of curiosity, how are you modifying it? for which use case? Sorry, I misspoke. Not modifying the API, but patching/wrapping the Proxy implementation to support other SES features. If anything, I would recommend to move away from the initial proxy design for Caja, because the harmony:proxies API is meant to never see light in the spec (and should probably be removed from Firefox). I agree that this is what we should be doing. However, we currently have to maintain ES5/3 (our emulation of ES5 on top of browsers that do not implement ES5, or do not do so correctly) which includes an implementation of Proxy. It's less work overall if we don't ditch harmony:proxies until we can also ditch ES5/3. Tom Van Cutsem wrote a direct proxies shim that runs on top of current browser implementations [4]. If you want to move to direct proxies, it might be something to consider. Indeed. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Wed, May 1, 2013 at 9:18 AM, Kevin Smith zenpars...@gmail.com wrote: - Dave, your argument that URI's as a naming mechanism is a failure cherry-picks cases where URIs were obviously overkill. What counterexamples should David have mentioned? -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On 5/1/13 at 1:37 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Ah, I'm not proposing that we augment the base Future class with cancellation properties. I explicitly used the term subtype in the quoted bit above. *Some* of Ron's suggestions were to augment the base Future class, but not all of them, and several other people pushed back on that. I think that covers the issue. Cheers - Bill --- Bill Frantz| Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module naming and declarations
On Wed, May 1, 2013 at 7:08 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Wed, May 1, 2013 at 9:18 AM, Kevin Smith zenpars...@gmail.com wrote:
- Dave, your argument that URI's as a naming mechanism is a failure
cherry-picks cases where URIs were obviously overkill.
What counterexamples should David have mentioned?
Well, it's Dave's job to come up with one, not mine ; P
Actually, I'm starting to think that the URI vs. unstructured names
argument is a bit of a tangent. These are the kinds of arguments to have
when designing a packaging system, not the core module system.
A clean separation between modules and packages will give us the freedom to
experiment with different approaches to inter-package dependency resolution
(IPDR, so I don't have to repeat it later). At the base level, we just
want URLs. Loader hooks can then be used to give special semantics to URI
subsets, or even to provide AMD-style URL overloading.*
We don't need to solve the IPDR problem with the core module system.
Instead, we can provide the primitives and see what flourishes.
{ Kevin }
*Note that CommonJS always blurred the distinction between packages and
modules.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
