What struck me from Jeremy's explanation was the uniformity of CoffeeScript's ?
operator (modulo the small issue he mentioned for function calls). It seems to
combine the currently-strawman'ed ??/??= and ?. into one very simple semantic.
What about adopting ?? as CoffeeScript's ? operator?
In our experience writing large apps, the distinction is useful. Undefined
means I forgot to do something (e.g. set a property or pass an argument); null
means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null =
my error
On Jun 14, 2012, at 14:03, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
In our experience writing large apps, the distinction is useful. Undefined
Machine-parsability might be reaching too far, especially if you lose the
benefits of nice function/method name inference. Instead, perhaps a separate
strawman to standardize something like the V8 stack trace API [1]?
It is used in Node for providing long stack traces [2], [3], [4]. It's a bit
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock
Sent: Friday, June 01, 2012 04:05
We haven't eliminated the ability to define object literals that inherit
from objects other than Object.prototype. We
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Mark S. Miller
Sent: Thursday, May 31, 2012 22:24
Non-strict mode is so bizzarre that I wouldn't be surprised, but I can't
think of an example. Is my proposed rule unsound
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, May 26, 2012 15:08
New syntax may some day clean all this up but the short path wins and
it'll be hard to displace. Let's be realistic. I agree
The prototyping efforts are appreciated, but can rarely be used in a
comfortable way. (Compared to, say, HTML5.) I've thought a lot about how to
feasibly use Harmony features in real-world code, but have fallen down every
time. Here are some of the stumbling blocks I've encountered:
* Node.js
You are of course right, Brendan, and thanks for addressing my points.
Certainly part of this was fueled more by frustration than informed knowledge
(see below).
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
The prototyping efforts are appreciated, but can
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead
reflecting the Traceur team's interpretation of where TC39 might eventually,
hopefully, end up.
I don't think this is a fair claim to make, considering Traceur had
I was going over the latest draft and noticed that, while binary and octal
literals have been introduced in 7.8.3, they weren’t added to 9.1.3.1
(“ToNumber applied to the String type”). Should they be?
Pros: symmetry. Cons: breaks backward compatibility (currently
ToNumber(0b1001) returns
Consider:
try {
doStuff();
} catch (e) {
console.log(uh oh, got an e, e);
throw e;
}
In Node and in all browsers I've tested with, this currently loses the stack
trace for `e`, and more importantly loses debugger step-back-ability in tools
like Firebug and Web Inspector.
One
smaller problem.
From: Rick Waldron [waldron.r...@gmail.com]
Sent: Friday, May 11, 2012 16:10
To: Brendan Eich
Cc: Domenic Denicola; es-discuss@mozilla.org
Subject: Re: Re-throwing errors
On Fri, May 11, 2012 at 2:43 PM, Brendan Eich
bren
I'm becoming increasing convinced that the poison pill approach to securing
the caller chain is a poor approach. We keep finding leaks in and it does
nothing to prevent implementation from inventing new ways to expose the
stating they are trying to hide. I now think we would be better off
As a day-to-day user who was not using strict until recently (stubborn other
team member for the loss), I can say that moving to strict was much more a
cleanup experience than a mode experience, with only a few small exceptions:
1) Poison-pilling arguments.callee: some code on the internet
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Angus Croll
Sent: Saturday, April 21, 2012 16:03
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: A few arrow function specification issues
4) Should it be a dynamic
Tangentially related: https://github.com/kriskowal/q/wiki/On-Exceptions
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Nebojša Ćirić [c...@google.com]
Sent: Tuesday, April 17, 2012 16:39
To: Jussi Kalliokoski
Cc: es-discuss
It seems rather non-intention-revealing.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mark S. Miller [erig...@google.com]
Sent: Tuesday, April 17, 2012 17:20
To: Brendan Eich
Cc: Tom Van Cutsem; Mark Miller; es-discuss
I'm sympathetic toward `undefined` as a sentinel for no value of the expected
type, whereas `null` means we have a value of the expected type, but that
value represents 'nothing.' Not sure if anyone else sees it that way, though,
and admittedly it's based on vague hand-wavey arguments.
The real question is, are there test-262's for this behavior? Or for the
original nonconforming `function true() { }`?
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mathias Bynens [math...@qiwi.be]
Sent: Thursday,
var tru\u0065; = Expected identifier error in IE9.
console.log(fals\u0065) = Syntax error in IE9.
Can test IE10 when I get home from work.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Brendan Eich
-boun...@mozilla.org] On
Behalf Of Domenic Denicola
Sent: Thursday, April 12, 2012 13:49
To: Brendan Eich; Allen Wirfs-Brock
Cc: es-discuss Steen
Subject: RE: Fun impossible Firefox JS challenge
var tru\u0065; = Expected identifier error in IE9.
console.log(fals\u0065) = Syntax error in IE9.
Can
We use `Function.prototype.partial` in our codebase. We consider
`Function.prototype.papply` but thought that would be too confusing with
`Function.prototype.apply`.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Axel
On Apr 7, 2012, at 20:37, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Sat, Apr 7, 2012 at 8:31 PM, Erik Arvidsson
erik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote:
On Sat, Apr 7, 2012 at 17:28, Rick Waldron
As a quick follow-up:
Perhaps adding non-arcane-incantation private name declarations would be enough
to push maximally-minimal classes from “nice, but are they worth it?” to “this
gives us something we can’t get anywhere else.” To wit:
class Set extends Collection {
private setContents,
Great to gain consensus indeed. This looks just about as nice as it can be.
Minor question: There are no examples of very empty arrow functions, e.g.
`=` or `= 5`. And from what I can tell reading the grammar , they are not
allowed. Is this necessary? CoffeeScript's allowance of `- (expr)`
On Mar 27, 2012, at 13:10, David Herman dher...@mozilla.com wrote:
I recognize the C.prototype.constructor idiom already exists, but it's a weak
idiom. I'm not crazy about the idea of strengthening a problematic but
currently unreliable and rarely used idiom.
Dave
Speaking as a dev, I
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if
it doesn't?
On Mar 23, 2012, at 16:28, Felix Böhm
esdisc...@feedic.commailto:esdisc...@feedic.com wrote:
Hi guys,
just a first try for a proposal: Array.prototype.[filter/some/every] currently
require a function
...@gmail.commailto:russell.legg...@gmail.com wrote:
On Mar 23, 2012, at 9:05 PM, John Tamplin
j...@google.commailto:j...@google.com wrote:
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from
Callable modules are a hugely important use case. jQuery and Underscore spring
to mind. I’ve made one myself [1].
Also important: what about construct-able modules? Or to put it another way,
what about exporting a module that is a class? Examples from Node [2] [3] and
Node-land [4] [5] are
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g. by
making them awkward via
, March 16, 2012 17:20
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: usable enough private names (was: Re: Using Object Literals as Classes)
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e
On Mar 16, 2012, at 18:05, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun
On Mar 16, 2012, at 18:12, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Sent: Friday, March 16, 2012 18:35
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: Re: Using Object Literals as Classes
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 19:28
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote
This wins on so many levels:
* Short but C-like myList.map((x) x*x) syntax for the most common cases, where
TCP doesn't matter.
* Full TCP support via an entirely new, but still pretty C-like, syntax with
myList.map((x) do { … }).
* The two are sufficiently close to each other and to the
If we’re taking votes:
-1. I would actively avoid using this in my own ES6 code, because of the
unnecessary confusion it would cause to those coming from CoffeeScript.
From: Carlos Prado García
Sent: Saturday, March 03, 2012 17:58:38
To: es-discuss
Subject: Re: How about replacing | with -
+1
I appreciate the feedback, but I do not understand the rationale.
The rationale I found compelling from upthread was that remove is a more apt
antonym to add.
To compare, delete's natural counterpart would be put.
___
es-discuss mailing list
: Tuesday, February 28, 2012 14:38
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org
Subject: Re: Typeof this in getters (was: eval on non-strings)
I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I just
tried it on very recent versions of 4
To clarify, the expected results here are:
Non-strict
Typeof this inside a function when called on a number: object
Typeof this inside an Object.prototype getter when used on a number: object
Strict
Typeof this inside a function when called on a number: number
Typeof this inside an
Perhaps using indexOfIdentical from
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, February
As a starting point, would it make sense to provide an API that matches
Array.prototype methods (where applicable)?
I think this ties in to my earlier desire to make Array.prototype methods work
with iterators in general [1]. That is, I think the correct way to do this
would be:
1) To
I am generally with Brendan that specifying __proto__ is not very necessary.
But, one thing I would like enshrined in the spec is that `__proto__ in
Object.create(null) === false`.
___
es-discuss mailing list
es-discuss@mozilla.org
This seems like a highly compelling argument. I hope I'm not the only one who
thinks the existing behavior of `for(;;)` makes sense. Granted, that comes from
understanding the detail that closures close over variables and not values,
which most users will not. But in general, `for(;;)` makes it
ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you want
lazy evaluation semantics (generators). Or perhaps you want to communicate that
the list is immutable (compare .NET's `IEnumerableT` or Java's
, Domenic Denicola
dome...@domenicdenicola.com wrote:
ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you
want lazy evaluation semantics (generators). Or perhaps you want to
communicate that the list is immutable
someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable
How about `someVeryLargeArray.asIterator().map(someFunction)`?
-Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
601 - 649 of 649 matches
Mail list logo
