@Jordan, thanks a lot! Switching to a personal account then.
@Tab other people in this thread have explained this throughly, but in
essence answering certain questions about dates require knowing
thetimezone offset.
For example knowing when "yesterday" was in an arbitrary timezone is not
just a
For prefetching we're calling LoadModule() for all the dependencies we want to
prefetch in the Fetch or Locate hooks.
For example, Systemjs has a System.depCache option which allows you to define
dependencies ahead of time. Here's the hook implementation:
There was discussion about using `this` for exposing metadata about the module.
For example (pure speculation):
this.address; // location of the current module
this.name; // name of the current module
this.metadata; // object with metadata generated during the loading lifecycle
this.loader //
In practice we've found that we rarely use the new Loader(hooks)` option and
instead this is more common:
var loader = new Loader();
var loaderFetch = loader.fetch.bind(loader);
loader.fetch = function (loadRecord) {
// do something
return loaderFetch(loadRecord);
};
This way we can think
On Monday, August 4, 2014 11:48 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Aug 4, 2014, at 16:33 , John Barton johnjbar...@google.com wrote:
As far as I can tell you are basically arguing that simple Loader hooks
don't need object state. Of course that is true.
No, I’m arguing
I don't have an answer, but the metadata property of the loadRecord object
was designed to be the place where you put your own custom metadata so that
it's persisted across hooks. And it works in es6-module-loader:
http://jsbin.com/kutey/2/edit?js,output.
Juan
On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports
On Tuesday, June 24, 2014 11:38 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
Say you wanted to add a hook which automatically added an export named
filepath to a module is the path to the file
For this use case and other similar ones it'd be nice if the `metadata`
property of load
On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
That's not valid ES6. It's specified that:
- Import and export statements can only be top level statements
-
On Thursday, June 19, 2014 5:17 AM, David Herman dher...@mozilla.com wrote:
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
My first reaction is to think that a lot of developers will ask: why
There are two options for prefetching dependencies without having to wait for
load and parse:
1) Assume none of your modules use the loader object for loading other modules,
parse them during deployment and get the dependency graph.
2) Use what Guy calls a tracer that executes your app during
On Monday, June 16, 2014 12:33 AM, Axel Rauschmayer a...@rauschma.de wrote:
**Single-export modules.** Still missing is support for single-export modules,
which could be added as follows (the keyword `default` instead of the asterisk
works just as well, in my opinion).
You're being
That answer made me very happy. Thank you Allen!
Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wednesday, May 28, 2014 7:27 PM, Ian Hickson i...@hixie.ch wrote:
One thing I don't see in the hooks above is anything to do with actually
processing dependencies. How would I (at the spec level) tell the ES6
module system that it should not evaluate a particular module until some
in order to cache it.
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
The Loader will know to wait for those dependencies.
I'm having difficulty understanding the spec for the instantiate hook.
Does it get called before the fetch hook? Is there some way to dynamically
add dependencies later
On Thursday, May 29, 2014 6:31 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
- some people want to predeclare a bunch of scripts and their
dependencies, without actually downloading any of them ahead of time,
and then later, when they're
On Tuesday, May 27, 2014 8:51 PM, Ian Hickson i...@hixie.ch wrote:
Is there a description of what the non-ES spec should say? That is, what
is the interface that System exposes that needs to be implemented by
this non-ES spec? What are the spec hooks that this non-ES spec would need
to
The latest draft doesn't seem to specify (or I can't find) where the Loader and
Module constructor object will be accessible from. Will they be available as
properties of the global object, as properties of System or as properties of
Reflect?
Thank you,
-
On Thursday, February 20, 2014 9:27 AM, joe joe...@gmail.com wrote:
Thanks. Btw, where is the final spec stored?
You can find it in the Drafts page:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts.
harmony:specification_drafts [ES Wiki]Draft Specification for ES.next
On Friday, January 31, 2014 8:10 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
what I'm talking about would be sugar for something functionally equivalent to:
```js
import 'bar' as ___temp1;
import 'baz' as ___temp2;
var foo = Math.random() 0.5 ? ___temp1 :___temp2;
```
I think it's good
On Tuesday, January 28, 2014 10:13 AM, Kevin Smith zenpars...@gmail.com wrote:
My take is that the difference between cast and resolve is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the
On Mon, Dec 9, 2013 at 2:36 PM, Till Schneidereit t...@tillschneidereit.net
wrote:
You could also check the output of Traceur and TypeScript. I don't know how
close either of them are to implementing the exact semantics of ES6 classes,
but I'm sure it'll be helpful in any case.
Yup. See
On Mon, Aug 26, 2013 at 12:54 PM, Mark S. Miller erig...@google.com wrote:
Since today this code will still typically work, and will in the near
future successfully become lazier, we should expect a lot of such code to
exist by the time we roll out our new standard. This brings us back to our
2013/8/8 David Bruant bruan...@gmail.com
2) A way to run a function after the current microtask and before
yielding back to the browser, same as what Object.observe() does. This is
what we need for promises and other library features that depend on some
level of asynchronicity and deal with
If then() deep flattens, flatMap() only flattens one level and promises
assimilate thenables, is branding really necessary?
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Does this all mean that you're ok with having promises-for-promises?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
2013/7/29 Brandon Benvie bben...@mozilla.com
My experience is that inheritance is usually done shallowly and these
collisions are rare and obvious when they happen.
It is not obvious when using mixins in UI code. Method names like
_onWindowResize are common and can easily lead to conflicts.
static properties of constructors have been used in JS mostly for
transport and avoiding pollution of the global object. For example
DOMPromise has Promise.any(), a static method. But if there were modules,
any() would probably be better suited as an export: import {Promise, any}
from @promise.
2013/6/9 Brian Di Palma off...@gmail.com
On Sun, Jun 9, 2013 at 4:18 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
No, we can't just blindly call GetValue in step 1 as that would lead to
the
get trap being invoked on a proxy (which is the wrong trap).
Why can't we have the two traps
Hello,
I'm having trouble understanding the current status of generators. Last
time I checked, the standard was what V8 has just implemented:
- Generator objects had next(), send(), throw() and close() methods
- These methods returned objects with value and done properties
It seems now that:
-
2013/6/8 Allen Wirfs-Brock al...@wirfs-brock.com
On Jun 8, 2013, at 1:42 PM, Juan Ignacio Dopazo wrote:
- All methods seem to return the yielded result, not an object with a
value property
No, yield produces a nextResult object. The last line of the yield
runtime semantics in 13.4.1.2
Now that it's been decided that braces are not a form of destructuring and
the colon replaced with `as`, what's the benefit of using braces? Why not
this previous proposal?
import foo as foofoo from foo;
import bar as bar;
Juan
___
es-discuss mailing
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
2013/4/30 Alex Russell slightly...@google.com
First, synchronous resolution needs some justification. I don't understand
why you've added it in the first design.
When I first read about the synchronous resolution flag I thought it made
sense, for example in the context of network requests.
2013/4/30 Claus Reinke claus.rei...@talk21.com
I have not yet been able to decide whether DOMFuture has a
similar provision, or how this note is meant to be interpreted.
I think it is covered by this language in the accept() algorithm:
Otherwise, the synchronous flag is unset, *queue a
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
Promise/A+ does not prohibit promises for promises. But in practice the
problem is
2013/4/26 Tab Atkins Jr. jackalm...@gmail.com
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
wrote:
Actually, I may have gotten it terribly wrong (apologies). In my
prototype
implementation, the following:
Future.accept(Future.resolve(1)).then(value = {
2013/4/26 Anne van Kesteren ann...@annevk.nl
If resolve called the thenable's then() with accept and reject, it would
only unwrap one layer.
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only
2013/4/26 Mark Miller erig...@gmail.com
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
the term future
What are the chances of the WHATWG renaming the spec to DOMPromise?
Juan
___
es-discuss mailing list
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 promises from thenables.
I don't think so. It has
2013/4/23 Ron Buckton rbuck...@chronicles.org
I fall mostly under the native futures should not implicitly chain
library futures camp. Its easy enough to write:
var p = // some thenable
return new Future(resolver = p.then(resolver.resolve, resolver.reject);
That looks terrible inefficient,
2013/3/25 Erik Arvidsson erik.arvids...@gmail.com
WeakMap would not work in this specific case since a WeakMap cannot be
iteratered.
I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or
just dropped?
Thanks,
Juan
___
2013/3/19 Andrea Giammarchi andrea.giammar...@gmail.com
@Juan I don't want the complexity of a Proxy, I want objects that inherit
from my private object so that what changes in my private object reflects
automatically everywhere.
Maybe you're misunderstanding my example. I'm not returning a
I'm surprised not to see Automatic Semicolon Insertion in the list.
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Nov 11, 2011 at 4:23 PM, Xavier MONTILLET xavierm02@gmail.com
wrote:
Object.getPrototypeOf(this) === Point.prototype = this instanceof Point
Actually, no. this instanceof Point = Object.getPrototypeOf(this) ===
Point.prototype, but not the other way around.
And I don't
On Sun, Oct 30, 2011 at 10:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I kind of like the rationale of: You (JS users) asked for classes *but
they really don't fit very well with the core concepts of the language*we
have to build upon.
Allen
Why? We have seen in more than one
On Sun, Oct 23, 2011 at 3:07 AM, Axel Rauschmayer a...@rauschma.de wrote:
- What do you call something that produces instances in JavaScript? A
class? A type? A constructor? Or is a constructor the implementation of a
type?
At least in my part of the everyday life of a JavaScript programmer,
On Thu, Oct 13, 2011 at 6:32 AM, Joe Developer joe.d.develo...@gmail.comwrote:
Truthfully the - arrow construct is one that I have an aversion to which
borders ( I'll admit ) on the irrational
My emails where private on purpose because all those arguments where made
before. Just look through
Hi! Is there anyone working on a Harmony transpiler besides Traceur? It'd
be really useful to have a transpiler that justs desugars (what's possible
to desugar) without using a library like Closure, the way CoffeeScript is
working nowadays.
Thanks,
Juan
On Tue, Oct 11, 2011 at 12:42 PM, John J Barton johnjbar...@johnjbarton.com
wrote:
On Tue, Oct 11, 2011 at 6:41 AM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Hi! Is there anyone working on a Harmony transpiler besides Traceur?
I'd like to understand why Traceur is not suitable
Thanks for all the answers!
On Tue, Oct 11, 2011 at 3:40 PM, John J Barton johnjbar...@johnjbarton.com
wrote:
I was trying to encourage Jake and Juan to participate in taking it
forward.
I'd love to, but I'm afraid my interpreter-writing skills are somewhat null
if not undefined. I'm
On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten rayn...@gmail.com wrote:
Object.create does indeed require propertydescriptors as the second
argument. This is the easiest way to send meta-data like read-only.
However it's verbose and the defaults are restrictive. I've written a small
library
On Thu, Oct 6, 2011 at 12:01 AM, Quildreen Motta quildr...@gmail.comwrote:
On 05/10/11 23:06, Brendan Eich wrote:
On Oct 5, 2011, at 7:01 PM, Quildreen Motta wrote:
On 05/10/11 22:05, Brendan Eich wrote:
On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:
- A sane way of dealing
Yes, tools should be better, but they need to start becoming better by
themselves as previous discussions here have noted.
However, there are problems in the language that need to be addressed by
both syntax and APIs. We need:
- A sane way of dealing with equality, identity and basically a lot
On Wednesday, September 14, 2011, David Bruant david.bru...@labri.fr
wrote:
Also, I would like to talk a little bit about terminology. WeakMaps have
their name inspired by the idea of weak references which have
particular garbage-collection properties. From the developer
perspective, this
On Mon, Sep 12, 2011 at 5:17 PM, Axel Rauschmayer a...@rauschma.de wrote:
Regarding tool support, adding type annotations in comments (JSDoc-style)
should be enough, mid-term.
For IDEs, it would really help if there weren’t so many competing standards
for even the most basic things in the JS
There is already a Node module that uses Proxies as a way of enforcing
promises:
https://github.com/sam-mccall/node-plate
It allows your to write:
var pfs = plate(fs);
pfs.writeFile('/etc/passwd.bak', pfs.readFile('/etc/passwd'));
pfs.end(function(err) { if(err) throw err; console.log(It's
On Thu, Jul 28, 2011 at 1:21 AM, Brendan Eich bren...@mozilla.com wrote:
Math functions
...
Can I add a request? Math.randomInt(n) returning [0, n) would be a nice
addition. Additionally but not necessarily, it could accept an optional
extra parameter for Math.randomInt(from, to). Most of the
On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:
Ah, I see. It's a fair point, but isn't this already a hazard that the
language faces?
Not with private names.
There's also something that was probably discussed
On Fri, Jul 8, 2011 at 12:15 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote:
My first thought was: why not just statically replace this.x, with private
x, with this[xPrivateName] and forget about accessing private properties
of other objects
On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:
You are very much right. What are the open issues with privates in classes
then?
The wiki lists some. Here are a few from memory:
* Syntax to use instead
On Wed, Jun 22, 2011 at 1:01 PM, Sean Eagan seaneag...@gmail.com wrote:
Its value is already resolved via prototype climbing, I don't see the
tremendous cost is simply making this value accessible within the
function activation which occurs as a result of the prototype
climbing.
Can the
On Wed, Jun 22, 2011 at 3:01 PM, Sean Eagan seaneag...@gmail.com wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be unambiguously resolved with prototype
climbing and without an extra implicit parameter?
Yes
On Mon, Jun 13, 2011 at 12:01 PM, Kam Kasravi kamkasr...@yahoo.com wrote:
On Jun 13, 2011, at 1:55 AM, Axel Rauschmayer a...@rauschma.de wrote:
Indeed a number of frameworks use 'initialize' for their 'ctor'. I imagine
this has been
heavily discussed within TC39, but perhaps some of the
On Wed, Jun 8, 2011 at 3:13 PM, Bob Nystrom rnyst...@google.com wrote:
That's better, but public and private are still less than ideal
keywords here since Javascript's use of them is distinctly different from
other languages. Alas, they were the best we could come up with.
public confuses me
On Tue, Jun 7, 2011 at 11:41 AM, David Bruant david.bru...@labri.fr wrote:
Le 06/06/2011 17:31, David Bruant a écrit :
myWeakMap.set(key, value) doesn't return anything. It could return the
previous value for the key (if such a thing exists). Is it intentional that
the set function doesn't
On Thu, May 19, 2011 at 9:40 PM, Brendan Eich bren...@mozilla.com wrote:
Not taking sides, just asking for you lurkers who use other libraries to do
similar counting exercises with those libraries, if you all can spare the
time. Thanks.
The reality is that in most cases libraries rarely use
On Wed, May 18, 2011 at 4:10 PM, Bob Nystrom rnyst...@google.com wrote:
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.com
wrote:
The whole of class declaration is a mouthful. 'function' and 'prototype'
are overlong too.
Sure. I'm not stuck on new, but in the chunks of
Since there's a call for developer feedback, I'll give mine.
Brendan once said JS is a curly-brace language and it always will be. I
think the - looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep
I've been thinking about something Brendan said in his last podcast about
how the community and TC39 can't agree on the syntax for class initializers
because of how flexible he made it at the beginning. So a little idea came
to me.
How about adding an Object.getMetaProperties or
Mixins are a great idea. Whatever decision is made about the position and
name of the inheritance declaration, they add a lot of value and are very
easy to understand.
A couple of related ideas:
class Vector {
superclass: Point, uses: Comparable
}
uses looks like a better fit. It's shorter
On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
Why not just to use already reserved `extends` keyword for specifying a
superclass? These XML-like braces looks not so elegant.
I asked this question a couple of days ago. The answer is quite simple.
Sure, it was discussed in this thread
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012963.html
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012963.htmlJuan
___
es-discuss mailing list
es-discuss@mozilla.org
One more question about the future of classes on Harmony.
Although the meta: property syntax is very clear, I'm wondering if it
isn't better to be less innovative and stick to what ES4/Java/etc have been
doing for a long time. Wouldn't something like this ease the learning curve
of the new
:46 PM, Juan Ignacio Dopazo wrote:
One more question about the future of classes on Harmony.
Although the meta: property syntax is very clear, I'm wondering if it
isn't better to be less innovative and stick to what ES4/Java/etc have been
doing for a long time. Wouldn't something like
Eich bren...@mozilla.com wrote:
On Mar 12, 2011, at 6:05 PM, Juan Ignacio Dopazo wrote:
Right, my bad then.
Maybe not, it's a difference but possibly someone will make the case for
it. I still favor putting 'constructor' on the class prototype (constructor
function .prototype in plain old ES5
Hi! I hope you don't mind a couple of questions about this proposal.
The superclass meta property definition says:
This causes the [[Prototype]] value of the new class’ prototype to be set to
the prototype property value of the designated constructor function
Shouldn't the superclass'
Correct me if I'm wrong, but I think it should be like this:
function S() {}
function C() {
Object.defineProperty(this, 'constructor', {
value: C,
enumerable: false,
writable: false,
configurable: false
});
}
C.prototype = Object.create(S.prototype);
var o = new C();
Right, my bad then.
Juan
On Sat, Mar 12, 2011 at 8:37 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 12, 2011, at 2:58 PM, Juan Ignacio Dopazo wrote:
Correct me if I'm wrong, but I think it should be like this:
function S() {}
function C() {
Object.defineProperty
79 matches
Mail list logo
