Equally as hackolicious (using the pending class properties proposal):
class X {
Y = () = {
...
}
}
-Jeff
On 6/11/15 2:16 PM, Matthew Robb wrote:
Here's a cool trick I found using this bind syntax today: Babel REPL
On 6/9/15 4:01 PM, Kevin Smith wrote:
how about introducing a well known concept in JS as `own` ?
```js
class Person {
static name String: A person name
own name String: anonymous
own items Array: []
Let's take a step back and ask: what's the motivation for
On 6/10/15 1:46 PM, Mark Miller wrote:
On Wed, Jun 10, 2015 at 8:59 AM, Jeff Morrison lbljef...@gmail.com
mailto:lbljef...@gmail.com wrote:
Instead, the purpose of initializers outside of the constructor
are to increase expressivity in a different sense than what I
think you
I am working on a proposal that I intend to bring to the next TC39
meeting. The (very much in need of updating) gist for my proposal is here:
https://gist.github.com/jeffmo/054df782c05639da2adb
(Note that this gist is from July of last year, which was before we
eliminated @@create and imposed
You might try reading through some of the previous threads that talk
about the trickiness of surfacing promise errors in the general case.
Unfortunately these threads usually devolve into an endless thread of
discussion and debate that become next to impossible to actually read
through later
On 11/13/14, 4:25 AM, Anne van Kesteren wrote:
On Thu, Nov 13, 2014 at 1:57 AM, Jeff Morrison lbljef...@gmail.com wrote:
Note that in my crazy idea I didn't say rethrow -- I carefully called it out as more of
a log than a throw.
I thought the plan was to have something equivalent
Even if async functions are changed to only be callable from an async
context or toplevel, they could still be promise-based from an
implementation's point of view.
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance for
On 11/12/14, 9:57 AM, James Long wrote:
Actually, it is possible we can do this without any extra syntax at
all (no `await^`). If we restrict async functions to only be able to
be called by other async functions, the engine should be able to keep
track of the async stack and throw errors
On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose
the promise being used to userland (to eliminate the chance for
userland to hold on to the promise and expect to be able to add an
error handler at any time).
And lose the
On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14, 4:10 PM, Kevin Smith wrote:
The only thing they couldn't do (under this proposal) is expose the
promise being used to userland (to eliminate the chance
Note that in my crazy idea I didn't say rethrow -- I carefully called it out
as more of a log than a throw.
Sent from my iPhone
On Nov 12, 2014, at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 12, 2014 at 2:49 PM, Jeff Morrison lbljef...@gmail.com wrote:
On 11/12/14, 5
If a constructor body contains an assignment of the form*this**=*then
automatic allocation is not performed and the constructor is expected to
perform manual allocation.
If I'm understanding this correctly, this means that snippet (A) would
never have access to `this`, but snippet (B) would
I'm not sure I understand your point here... Are you saying that the
only way to solve the DCE/refactoring problem is to either always
implicitly allocate or never implicitly allocate?
-Jeff
On 9/12/14, 7:22 AM, Claude Pache wrote:
Le 12 sept. 2014 à 08:39, Jeff Morrison lbljef
On 9/11/14, 10:22 AM, Florian Bösch wrote:
A - B - C - D - E changes to
A - B - C - D - async E and causes
A await - B await - C await - D await - async E
And of course if A, B, C or D is used anywhere else it percolates
trough the entire call graph.
Sort of true, but this is no worse than
I was just talking with a co-worker today about why it's ok for 'catch'
to be a property name, but not a variable identifier. It's clear that
the reasoning here is because property names aren't restricted by
reserved words, but it's unclear why 'catch' must be reserved to begin with?
I had
That's a great point, thanks.
On 6/17/14, 12:36 PM, C. Scott Ananian wrote:
My guess would be that `catch` is reserved so that (in a future
version of JavaScript) this won't be ambiguous:
```
try { stuff(); }
catch(e1) { }
catch(e2) { }
```
Currently JS only allows a single catch clause. But
Ok, so I've read most of the Promise.cast/Promise.resolve thread and
it's gone back and forth and branched in topic several times...but now
I'm a bit confused as to where we sit (and navigating that thread again
isn't the most exciting idea). So can someone who's been following that
thread
IIRC the purpose of separating the two was to encourage the idea that
you should not normally iterate over both (because symbols will often be
used to publicly obfuscate properties on an object).
Originally symbol keys were not enumerable at all. However it was hard
to show that enumerating
On 11/1/13, 11:32 AM, James Burke wrote:
On Thu, Oct 31, 2013 at 8:32 PM, Jeff Morrison lbljef...@gmail.com wrote:
Throwing this out there while I stew on the pros/cons of it (so others can
as well):
I wonder how terrible it would be to have this API define module bodies in
terms of a passed
(I'm operating on the assumption that the Module constructor is still
part of the spec):
```
System.define({
A: {
deps: ['B','C'],
factory: function(B, C) {
var stuff = B.doSomething();
return new Module({stuff: stuff});
}
},
B: {
deps: ['D', 'E'],
factory:
This is excellent, but I had been worried about a string/eval-based
define() API as well.
Throwing this out there while I stew on the pros/cons of it (so others
can as well):
I wonder how terrible it would be to have this API define module bodies
in terms of a passed function that, say,
So I think during the last meeting it was decided that we'd now have two
scopes for functions with default param values: One for head/params, and
one for the function body.
Was it also agreed that we'd use let-binding (vs var-binding) for the
default-value expressions?
I also just wanted to
Typo in first scenario fixed
On 9/30/13 1:17 PM, Jeff Morrison wrote:
So I think during the last meeting it was decided that we'd now have
two scopes for functions with default param values: One for
head/params, and one for the function body.
Was it also agreed that we'd use let-binding (vs
On 7/5/13 9:53 PM, Allen Wirfs-Brock wrote:
On Jul 5, 2013, at 5:27 PM, Jeff Morrison wrote:
I'm reading through the spec and trying to understand whether static methods on
harmony classes are inherited by their subclasses or not, and as far as I can
tell they are not -- is this correct
PM, Jeff Morrison wrote:
I'm reading through the spec and trying to understand whether static methods on
harmony classes are inherited by their subclasses or not, and as far as I can
tell they are not -- is this correct?
Yes, they are inherited as properties of subclass constructors
I'm reading through the spec and trying to understand whether static
methods on harmony classes are inherited by their subclasses or not, and
as far as I can tell they are not -- is this correct?
I see that the harmony class wiki suggests this topic is an open issue
-- but the maximally-minimal
functions.
-Jeff
On 6/5/13 7:55 AM, Brendan Eich wrote:
Jeff Morrison wrote:
require() is a synchronous call in to our module system, and we don't
execute a given module until all of its require() dependencies have
been downloaded.
Hi Jeff, catching up (sorry if I missed it): do you do
I still kinda like the idea of allowing ImportDeclarations to be
expressed anywhere inside a ScriptElement (including in its children),
and then hoisting the declaration for compilation/linking, but only
executing the dependency when the statement is reached at runtime. It is
then a parse
the dependency-graph of a file (for
packaging, etc).
-Jeff
On 6/4/13 9:37 AM, Jeff Morrison wrote:
I still kinda like the idea of allowing ImportDeclarations to be
expressed anywhere inside a ScriptElement (including in its children),
and then hoisting the declaration for compilation/linking
On 6/4/13 9:52 AM, Jason Orendorff wrote:
On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison lbljef...@gmail.com
mailto:lbljef...@gmail.com wrote:
FWIW this is what we have been doing at Facebook for a while now
(over a year), and it's worked pretty well for us.
We use a require
Big +1 on being able to defer execution until explicit import. It
definitely seems useful to allow for control over dependency
specifications separately from [potential] dependency execution. More
concretely, I don't think you could do something like the following with
the current module spec
`import foo from foo;` reads to the quick eye as import the symbol
named foo from the module named 'foo' -- but that's not actually what
it means (wrapped curlies be damned!).
I think the syntax would read much less confusingly if we made use of a
`default` keyword to signify better what's
32 matches
Mail list logo
