One of the pieces of awkward ES specification terminology has been the use of
the word Program as the name for a global top-level StatementList. A ES
Program is commonly only a single fragment of what most of us commonly
think of as a program.
I agree.
I proposed that we replace Program
On Oct 10, 2012, at 4:20 PM, Rick Waldron waldron.r...@gmail.com wrote:
-1
Script might be the most common execution context, but there is more then
one of those to consider. I think Program is just the right amount of
neutral.
This doesn't address Allen's point, though, which is that a
On Sep 24, 2012, at 12:37 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
I want to defend my kind of nannying. :-)
I favor rejecting `if x = y` in comprehensions because it's almost
always going to be a bug, and a tough bug to diagnose.
I don't. Where do you draw the line? if (x = y)
It's still early to say. But my feeling is that if we can get macros working,
we can introduce new syntax via modules, not just unconditionally throwing them
in everywhere. Then you don't have to do these kinds of global conditional
things; rather, you just import the syntax from modules. The
On Aug 8, 2012, at 11:23 AM, Brendan Eich wrote:
The other advantage of an Object.extend or Object.update function is that
developers can polyfill. Yes, Object.extend in JS libraries relies on for-in
-- but Object.prototype is verboten, so that's mostly ok by convention.
The point is not
On Aug 8, 2012, at 3:08 PM, Axel Rauschmayer wrote:
I'm not yet convinced that Object.update should be restricted to own
properties. If you're only using object literals, then yeah, you want own
properties only; you're basically using object literals as a poor man's
named arguments. But if
On Aug 8, 2012, at 2:23 PM, Brendan Eich wrote:
So if we do add :=, we should allow it to work on variables too, for
consistency.
See above -- := is not a drop-in replacement for =. Think of it more like the
.{ proposal...
With too many of these conversations about various modify an
On Aug 8, 2012, at 5:01 PM, Brendan Eich wrote:
The problem is that neither = nor Object.defineProperty can be used
succinctly and reliably to shadow or override.
OK, that's the real problem, thanks for making it clear -- sorry if I missed it
before.
Allen should correct me, but I think he
On Aug 1, 2012, at 3:44 PM, Brendan Eich wrote:
One possibility is : moniker
While I recognize the benefit of staking out new territory, I think that misses
the opportunity to build off of existing intuitions. I tend to think it's ok to
use a term from another language that isn't 100%
On Aug 1, 2012, at 3:53 PM, Mark S. Miller wrote:
On Wed, Aug 1, 2012 at 3:44 PM, Brendan Eich bren...@mozilla.org wrote:
[...] However in print, Name can work as well as Symbol or other terms.
If we call the category of things that Object.getOwnPropertyNames does
not return Names, ...
On Aug 1, 2012, at 4:20 PM, Kevin Reid wrote:
On Wed, Aug 1, 2012 at 3:56 PM, David Herman dher...@mozilla.com wrote:
In the Lisp world, strings and symbols are isomorphic, but there's a sense
that symbols have identity where strings don't. Now, Lisp symbols are
historically forgeable
On Aug 1, 2012, at 4:45 PM, David Herman wrote:
...
Sure, some Schemes have uninterned symbols as well.
Oops, meant to snip my own text there as well, since I addressed uninterned
symbols further down. Hope it didn't come across rude.
Dave
On Jul 20, 2012, at 2:01 PM, ๏̯͡๏ Jasvir Nagra wrote:
1. What is part of the fresh module scope? Sam has clarified that it closes
over lexically scoped variables and Dave has clarified that no variables are
closed over in the external case. What else is included? Can an external
module
On Jul 20, 2012, at 9:23 PM, Isaac Schlueter wrote:
On Fri, Jun 29, 2012 at 4:33 PM, David Herman dher...@mozilla.com wrote:
var fs = require('fs')
// no path here...
function notCoveredByTests () {
fs.open(path.resolve(yabbadabba), ...)
}
Right.
How would any of this solve
On Jul 17, 2012, at 9:17 PM, ๏̯͡๏ Jasvir Nagra wrote:
However, Module Semantics
(http://wiki.ecmascript.org/doku.php?id=harmony:modules_semantics) suggests
that each inline module declaration introduces a fresh scope.
As in, a fresh *nested* scope.
Given this, I am trying to understand
On Jul 18, 2012, at 9:15 AM, ๏̯͡๏ Jasvir Nagra wrote:
On Wed, Jul 18, 2012 at 4:25 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
Lexical bindings as well as module definitions:
module outer {
let x = 1;
export module inner {
export y = x + 2;
}
}
That's a little
On Jul 2, 2012, at 7:19 AM, Kevin Smith wrote:
Dave, is it possible to create an effectively synchronous loader using the
Loader API?
Yes, I would certainly want to allow this. I also figure there's nothing wrong
with a host environment choosing to add additional synchronous API's to the
Just a heads up that I'll be communicating very little by email starting
tomorrow late afternoon and until the 14th.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jun 30, 2012, at 11:46 AM, John J Barton wrote:
On Sat, Jun 30, 2012 at 11:24 AM, Kevin Smith khs4...@gmail.com wrote:
So we have a situation where legacy.js must be executed PRIOR TO
INITIALIZING main.js. This violates the order-of-execution semantics for
both ES6 modules and for Node
On Jun 27, 2012, at 1:06 PM, Isaac Schlueter wrote:
On Wed, Jun 27, 2012 at 11:51 AM, David Herman dher...@mozilla.com wrote:
That bug was particularly bad because it was *assigning* to an accidentally
global variable. But in my personal experience I certainly forget to import
common
On Jun 27, 2012, at 8:46 AM, Isaac Schlueter wrote:
I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem. Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what JS is
all about.
Well, not JavaScripty is
On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote:
On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich bren...@mozilla.org wrote:
var foo = 42;
... foop ...
throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you
wrap a module around that hunk of code, and there's no
On Jun 27, 2012, at 11:00 AM, Jussi Kalliokoski wrote:
On Wed, Jun 27, 2012 at 8:43 PM, David Herman dher...@mozilla.com wrote:
http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
I don't see how that's at all related to modules or how modules would have
prevented
On Jun 27, 2012, at 10:58 AM, Kevin Smith wrote:
The client chose to use *. You don't have to use * if you don't want to. It's
a convenience.
The convenience of * comes with a price, of course: (a) the inability to
statically catch undeclared names without also anlayzing external files,
On Jun 27, 2012, at 11:15 AM, Isaac Schlueter wrote:
That was a bug caused by a lack of global isolation, which current
module systems cannot fix.
It was caused by accidentally creating a global variable instead of a local
variable. Not totally sure what you mean by global isolation? If you
On Jun 27, 2012, at 11:40 AM, Jussi Kalliokoski wrote:
This brings up an interesting point about the modules, that being lazy
loading. One appealing reason to use a module loader instead of just
concatenating the scripts or using multiple script tags is that you can do
feature detection
Implicit coercions suck, and IMO it would be better if destructuring didn't add
new ones to JS. In the current draft spec, I believe if you match an object
destructuring pattern against a non-object or an object that doesn't have one
or more of the properties, it quietly proceeds -- masking
On Jun 20, 2012, at 9:37 PM, Erik Arvidsson wrote:
In our previous discussion I had come to the understanding that the
default iterator would use a private name. The main benefit for using
a private name is to not pollute the property name space.
import iterator from '@iter';
On Jun 15, 2012, at 5:57 PM, satyr wrote:
On Sat, Jun 16, 2012 at 4:33 AM, David Herman dher...@mozilla.com wrote:
As for null, I can see how there's confusion about whether to use null vs
undefined, and so I can see why CoffeeScript would just try to blur the
distinction between them
On Mar 23, 2012, at 8:16 AM, Steven Levithan wrote:
Although this is only a minor convenience since you can do something like
text.replace(/[-[\]{}()*+?.,\\^$|]/g, \\$), the list of special characters
is subject to change.
That sounds like another good argument for standardizing.
The only
On Jun 14, 2012, at 1:45 PM, Brendan Eich wrote:
I can see adding ?? and ??= (undefined-only, not undefined-or-null).
I think ?? is the highest priority.
Is ||= really worth it? It would not assign if the left side is truthy, but
perhaps no one will mind.
Given ||= is there any oxygen
On Jun 12, 2012, at 10:52 PM, Brendan Eich wrote:
People don't default on the caller side (at the callsite) much, in my
experience. Dave may be seeing other sources, but it's extremely rare in my
experience to see
foo(arg1 || callers_idea_of_default_arg1_value);
I'm sure it's more rare
On Jun 12, 2012, at 11:44 PM, Thaddee Tyl wrote:
Besides, it often has a similar meaning: I have seen in a lot of code
a de-facto standard wherein null is used to indicate a value that is
voluntarily undefined. You can see this pattern all over node.js code,
for instance.
I *think* this is
On Jun 12, 2012, at 11:02 AM, Brendan Eich wrote:
It's possible ?? or however we spell it isn't worth adding, while ?= is. The
conditional assignment to default or normalize is the prime use-case.
I'm skeptical. You don't foresee
f(obj.x ?? defVal)
happening a lot? I do.
Dave
On Jun 12, 2012, at 7:41 PM, Ryan Florence wrote:
I'm skeptical. You don't foresee
f(obj.x ?? defVal)
happening a lot? I do.
I can't speak for the world but I've never seen anybody do f(val ||= defVal)
in Ruby or CoffeeScript.
But I'm not talking about ||=. I'm talking about the
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
My point still stands. Being undefined-specific is arbitrary.
CoffeeScript could have been undefined-specific; they were
undefined + null-specific, which I believe makes more sense.
Can you make the full argument? I'm genuinely undecided on this
I wrote a new strawman for Error stack which is now available in some
form in all major browser (if betas are considered).
Thanks for writing this up. I left a couple comments on the strawman, but I
should just respond here.
- I'm in favor of trying to come up with a common format as much as
On Jun 1, 2012, at 2:54 AM, T.J. Crowder wrote:
Hey, no stress -- always happy to have input. Just please, no more bogus
comparisons to `with`.
Could we please avoid derogatory terms like bogus? I'm talking about what
people see when they look at code (more below). That's a valid
On Jun 1, 2012, at 8:52 AM, Kevin Smith wrote:
Regarding private names: I'm not convinced that private, non-reflective
names are unproblematic in and of themselves. I would personally like to see
more exploration on this front, with concrete use-cases. What useful things
can we do with
On Jun 1, 2012, at 12:26 AM, Allen Wirfs-Brock wrote:
These can (and now are) all done in multiple imperative steps. Mustache
allows all of these sorts of object extensions to be accomplished using the
exact same beautiful object literal syntax.
A beautiful syntax for something that can
On Jun 1, 2012, at 10:10 AM, Oliver Hunt wrote:
Also, I won't be around on email for the next week or so as I'm helping out
on the ALC (if you feel like sponsoring here's a url:
http://www.tofighthiv.org/site/TR/AIDSLIFECYCLE11/AIDSLifeCycleCenter?px=2583919pg=personalfr_id=1440)
Go Ollie!
On May 31, 2012, at 2:52 AM, T.J. Crowder wrote:
I'm worried this looks a lot like `with` -- with the same issues.
No. No.
This does not involve the object with the scope chain in any way.
Is the idea that unqualified references would be _required_ to be properties
of the object in
On May 31, 2012, at 11:13 AM, Russell Leggett wrote:
If you reframe the problem as |this| just being another parameter, this whole
debate seems quite silly to me. Any function that is written to have a |this|
value be dynamic, and possibly set by the caller can be rewritten as a
function
On May 31, 2012, at 4:12 AM, Andreas Rossberg wrote:
4. The leading dot seems, to me, to be more explicit than just having the
first symbol on the left being implicitly a property the object. EIBTI
I agree with that.
As I said in another thread, it's not going to happen because of the ASI
On May 25, 2012, at 5:29 AM, Rick Waldron wrote:
On Fri, May 25, 2012 at 2:10 AM, François REMY fremycompany_...@yahoo.fr
wrote:
While we're at it, I had an idea to allow to avoid the function*() {} syntax:
why not yield [noLineTerminator] return ?
This approach expects all future
On May 31, 2012, at 5:30 PM, T.J. Crowder wrote:
On 1 June 2012 00:51, Brendan Eich bren...@mozilla.org wrote:
Dave's cascade proposal:
http://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/
Thanks. With a great deal of respect, I'm not seeing how that isn't
with-lite with
On May 31, 2012, at 7:08 PM, T.J. Crowder wrote:
On 1 June 2012 01:40, Brendan Eich bren...@mozilla.org wrote:
Let's be precise. You keep bringing 'with' up but it's not relevant to the
cascade proposal, going by Dave's definitions. If you have the appearance of
'with' concern I call out
On May 31, 2012, at 6:06 PM, Rick Waldron wrote:
The original API allowed me to pass an explicitly bound callback (whether it
was by bind or fat arrow) and have that binding take precendence over a
default behavior.
I think you might still be missing a key point: if `callbackFn` is a bound
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should mean, I can offer some examples
of when I would do this.
Could you? I
On May 31, 2012, at 9:31 PM, Brendan Eich wrote:
This may seem not much of a difference, but it's major not only due to the
typo and array-not-an-Array-instance cases. The scope chain extension is
costly and forces deoptimization in common implementations. And of course
'with' is banned in
On May 31, 2012, at 9:50 PM, David Herman wrote:
...but it could be captured by the `with` object or one of its properties.
s/properties/prototypes/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On May 31, 2012, at 9:50 PM, David Herman wrote:
Whereas with cascades, you'd get:
var obj = {
log: console.log.bind(console),
foo: function() { Object.prototype.bar = captured }
};
var bar = local variable;
with (obj) {
log(bar); // local variable
It's become clear to me that mustache syntax is not well motivated. As a simple
update for objects, there's little it can do that Object.extend couldn't do. I
thought with my cascades proposal that it might gain more justification (to
allow the fluent aka chainable style even for methods that
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
Same thoughts here. Regular devs (like me!) only see
[[DefineOwnProperty]] when creating a literal, and then there's no
observable distinction between these two in normal circumstances:
Bingo. The different between [[DefineOwnProperty]] and
On May 29, 2012, at 9:59 AM, Nicholas C. Zakas wrote:
var element = document.getElementById(myDiv);
element.{
innerHTML: Hello world!,
className: enabled
};
Great example. With my proposed operator, it would instead be:
var element = document.getElementById(myDiv);
element.{
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
Given that these two are identical to most devs, giving them distinct
syntaxes in the strawman is problematic. Further, and much more
importantly, [[DefineOwnProperty]] is *nearly never* the behavior that
a dev will actually want. Devs are
On May 29, 2012, at 10:56 AM, Allen Wirfs-Brock wrote:
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
If it's desperately important that we don't make obj.{foo:bar} do a
[[Put]], then it would be much better to simply not allow that syntax
*at all*. ...
Language design and extension
On May 30, 2012, at 2:48 PM, Herby Vojčík wrote:
You need (need in the sense having readable construct to perform) .{...}
with [[DefineOwnProperty]] not for foo:bar (yes, there [[Put]] should
happen), but for dynamically adding concise methods and/or getters/setters to
objects.
Using
On May 29, 2012, at 9:00 PM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right
On May 30, 2012, at 2:18 PM, Mark S. Miller wrote:
However, there might be some utility (at least for debugging) in having a
Function.prototype.isThisBound method. It would return true for arrow
functions and functions created via Function.prototype.bind
I agree that such a predicate
On May 30, 2012, at 3:16 PM, Herby Vojčík wrote:
I can read literal extension in the same way: this is a bunch of data, make
the receiver object contain that data in it.
OK, but that agrees with my point, which is that the : doesn't carry an
operational connotation. To be specific, if the
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for can.
What guarantee are you trying
On May 30, 2012, at 4:00 PM, Axel Rauschmayer wrote:
I was mostly concerned about concise methods.
For most cases, you just want [[Put]]. And I favor thin arrow for concise
standalone methods/constructors.
How about the following use case? Adding a method with a super-reference to
an
These are a combination of my edits of Rick's notes from the first topic, my
notes from subsequent topics, and then my reconstruction from memory of the
conversation on the last topic. So for those present, please feel free to
correct the record.
Dave
On May 22, 2012, at 9:29 AM, Erik Arvidsson wrote:
I think this proposal has one fatal flaw and that was what brought it
down the last time we had a proposal which used the same concepts.
Given:
class C(x) {
public method() {
return x;
}
}
It seems like the arguments to the
On May 10, 2012, at 1:05 AM, Brandon Benvie wrote:
On this tangent, I personally almost always mean isArrayish in this very
common situation. That is, indexed with a length such that almost all
Array.prototype methods would work on it out of the box. The number of
arrayish interfaces
On May 8, 2012, at 9:19 AM, Rick Waldron wrote:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
Changing typeof null always seemed questionable to me in terms of value. It
doesn't really give you significant new functionality, it just kinda seems
more sensible.
On Apr 24, 2012, at 9:51 AM, Rick Waldron wrote:
On Tue, Apr 24, 2012 at 12:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 23, 2012 at 3:36 PM, David Herman dher...@mozilla.com wrote:
box = {
_value: 0,
get: () - this._value,
set(v) { this._value
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this) functions.
(Edit: Oh, I see, leaning on the completion value of thin-arrow
functions here lets you shave a few characters off. The readability
loss of mixing the two
On Apr 24, 2012, at 2:09 PM, Allen Wirfs-Brock wrote:
On Apr 24, 2012, at 1:40 PM, David Herman wrote:
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this)
functions.
(Edit: Oh, I see, leaning on the completion value
On Apr 21, 2012, at 1:38 PM, Angus Croll wrote:
a function shouldn’t work radically (and silently!) different depending on
how it is invoked
every current JS function behaves exactly this way :-)
No, not at all. What Axel is saying is that you're proposing a new distinction
that *does not
On Apr 23, 2012, at 2:45 PM, David Herman wrote:
You cannot distinguish whether a function was called as a method, as a
function, or via .call/.apply. There's no way to tell.
PS Well, there's stack inspection, but we're all grownups here.
Dave
On Apr 23, 2012, at 3:53 AM, Alex Russell wrote:
This means that most users of most functions can still use .call() and
.apply() without apprehension. Functions are still just functions.
You're assuming your conclusion: that there's some sort of platonic ideal
(just functions) of JS
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical, there
aren't many strict mode changes left IIRC, and they are pretty edgy edge
cases.
True enough, but I hang tough on wanting arrows to imply
On Apr 19, 2012, at 2:18 PM, Allen Wirfs-Brock wrote:
//initialize some variable with default objects
let {
unidentifedAdult: mom,
unidetifiedAdult: dad,
unidentiedChild: brother,
unidentifiedChild: sister
} = peopleConstants;
why is this less desirable than:
Hi Xavier,
It's great to see this project! I'll take a closer look soon. I will see if I
can help contribute to this.
Dave
On Apr 18, 2012, at 5:20 AM, Xavier CAMBAR wrote:
Hi,
I wanted to announce that I've been working on a project called Shepherd
Agreed. This is easy to spec and implement, highly composable (it fits neatly
into the algebra of destructuring patterns everywhere, as opposed to just in
object property-name positions), has no problems with side effects, and does
not violate restrictions that IINM strict mode is supposed to
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 10:10 AM, Brendan Eich wrote:
In general, delegation (depth D) plus optionality (degree N paramters) makes
an (2N)^D worst-case combinatorial explosion.
This is IMHO a strong argument for a sentinel in-language to
On Apr 13, 2012, at 9:38 AM, Russell Leggett wrote:
Yes, but as I said, and Erik pointed out is in the wiki, it is a lot more
likely that someone would pass f(foo) or f(obj.foo) where foo might be
undefined.
Bingo.
Expecting undefined as a possible valid argument (as opposed to a missing
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
foo(undefined);
1, 2, 1
foo(3);
3, 2, 1
foo(undefined, undefined);
1, 2, 2
foo(undefined, 3);
1, 3, 2
foo(3, undefined);
3, 2, 2
On Apr 13, 2012, at 11:46 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 11:22 AM, David Herman wrote:
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
That sentinel could simply be a empty argument position:
new Intl.Collator( , {usage: search});
That's not enough
On Apr 13, 2012, at 11:51 AM, Allen Wirfs-Brock wrote:
both sides of this debate seem a little smelly. But, Pretending that
undefined isn't a real value seems more smelly to me.
There's no need to think of it as pretending it's not a real value. Think of it
as saying that the undefined value
On Apr 13, 2012, at 11:48 AM, David Herman wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
Oops: 1, 2, 0
Dave
___
es-discuss mailing
On Apr 13, 2012, at 12:05 PM, Oliver Hunt wrote:
On Apr 13, 2012, at 11:48 AM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
foo(undefined);
1, 2, 1
Uh what? I pass no arguments and arguments.length is 2, and i pass one
argument
On Apr 7, 2012, at 1:40 PM, Erik Arvidsson wrote:
This does not work for rest parameter since ... is only allowed inside
array literals.
var tail = (x, ...xs) = xs;
This can of course be solved in numerous ways but it is not true that
the Expression is a cover grammar for
Hi James,
1) Multiple mrls for System.load():
System.load(jquery.js, underscore.js, function ($, _) {})
or
System.load([jquery.js, underscore.js], function ($, _) {})
Makes sense. The former is a bit muckier but more convenient than the latter.
I'll play with the alternatives, thanks.
---
Benefits of compile time binding
---
This is what I need help in understanding. The benefits I have heard so far:
1) Being able to check export names/types. As mentioned, this feels
like a very shallow benefit, since it does not apply to properties
outside of the
On Mar 31, 2012, at 6:47 PM, David Herman wrote:
This can be and has been done in other dynamically typed languages [1], and
it can be done for JS, too.
[1] http://www.ccs.neu.edu/home/stamourv/papers/numeric-tower.pdf
___
es-discuss mailing list
es
On Mar 31, 2012, at 11:11 AM, James Burke wrote:
We should try for the equivalent of import *, sorry if I was too short
on this point. I'll expand what I meant:
I think it should be a runtime-like thing (probably using the wrong
word there), and just allow it for any object via
On Mar 30, 2012, at 7:42 AM, Claus Reinke wrote:
DaveH's presentation about module loaders
Shouldn't any newly designed async loading APIs support promises?
No, for the very simple reason that promises have not been standardized and
won't be in ES6.
For ES proposals, promises seem to be
On Mar 29, 2012, at 6:23 AM, Domenic Denicola wrote:
Bigger question: It sounds like TCP was sacrificed in favor of maximal
minimalism, which makes sense.
No, maximal minimalism is not our universal principle for ES6. It's important
for classes, for various reasons, but it's not our approach
On Mar 28, 2012, at 2:19 PM, Erik Arvidsson wrote:
With your proposal I have to do let f = obj.foo;
obj::f which is even longer than the original.
That's not a fair argument. There's no need for the let-binding; you can write
obj::obj.foo
or
::obj.foo
Now, you might feel that it's
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case is
passing a method as an argument but needing to retain the correct this.
Obviously, that is what bind was meant for, but that is inconvenient when
passing methods for
On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:
This is actually one of the reasons I still come down on constructor over
new - I'd really like to discourage screwing around with
ctor.prototype.constructor. That always felt like a major wart IMO. Making
it ReadOnly/DontDelete would be
On Mar 24, 2012, at 5:54 PM, Allen Wirfs-Brock wrote:
I primarily favor sticking with constructor because the
safety/maximally-miminal proposal is all about being conservative...
I think you'll find what I'm saying is as conservative as what you've been
advocating. Your reply demonstrates
On Mar 24, 2012, at 11:23 PM, Norbert Lindenberg wrote:
On Mar 24, 2012, at 12:21 , David Herman wrote:
I'm still getting up to speed on Unicode and JS string semantics, so I'm
guessing that I'm missing a reason why that wouldn't work... Presumably the
JS source of the regexp literal
On Mar 24, 2012, at 10:20 PM, Allen Wirfs-Brock wrote:
On Mar 24, 2012, at 7:29 PM, Brendan Eich wrote:
I suspect Dave misinterpreted Nadav's question. So did I, when I originally
read it.
Oh, yes, thanks for the clarification. I thought he was talking about the
superclass position, but
On Mar 24, 2012, at 10:54 PM, Brendan Eich wrote:
It's the right trade-off, and not just to get appropriately minimal classes
into ES6 -- the computed method case is often part of a generative framework
anyway, so won't obviously fit into any general, declarative syntax.
Since we've gone
On Mar 25, 2012, at 10:30 AM, Brendan Eich wrote:
Still, I prefer to defer anything like the above (and of course, defer the
better traits thinking you showed).
Yep, definitely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 23, 2012, at 1:17 PM, Brendan Eich wrote:
class Point extends Evil {
constructor(ax, ay) {
public x, y;
super();
this.x = ax;
this.y = ay;
}
...
}
class Evil {
constructor() {
console.log(this.x);
}
}
Should undefined by
201 - 300 of 654 matches
Mail list logo
