My 2 cents against the windmills...
I personally think returning `this` in absence of any meaningful value (and
chaining in general) is a bad pattern. Chaining leads to worse readability
(there's nothing subjective about this, if you have to scan the code to
another page to figure out which
On Tue, Dec 4, 2012 at 3:34 AM, David Herman dher...@mozilla.com wrote:
Typed Arrays will become a special case of binary data objects. In other
words, the binary data API generalizes typed arrays completely.
Sounds like a plan!
Yes, but with some exceptions. We will be extending the API
Language specification is a difficult task, especially when handling a
complex language, legacy spec style, and wide variety of audience
background, not to mention a committee with lots of feedback and opinions.
We are very lucky that Allen does the job he does.
Yes. That doesn't mean he should
Le 4 déc. 2012 à 22:28, Brendan Eich bren...@mozilla.org a écrit :
Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eichbren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path.
On Wed, Dec 5, 2012 at 5:04 AM, Claus Reinke claus.rei...@talk21.com wrote:
if you were browsing the spec trying to figure out what
super is about in JS, how much of the spec would you have to
read to answer that question, and how many readers succeed?
This is a very clear statement of the
Claude Pache wrote:
Le 4 déc. 2012 à 22:28, Brendan Eichbren...@mozilla.org a écrit :
Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eichbren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple,
Date: Tue, 4 Dec 2012 11:03:57 -0800
From: bren...@mozilla.org
Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
Allen Wirfs-Brock wrote:
It's less clear which is the best choice for JS.
Cascading wants its own special form, e.g., Dave's
mustache-repurposed proposal at
On Wed, Dec 5, 2012 at 10:06 AM, Nathan Wall nathan.w...@live.com wrote:
Date: Tue, 4 Dec 2012 11:03:57 -0800
From: bren...@mozilla.org
Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
Allen Wirfs-Brock wrote:
It's less clear which is the best choice for JS.
Cascading wants
For what is worth it , I don't believe everyone does it like that has
ever been a valid argument. Maybe everyone simply copied a pattern from
jQuery without even thinking if it was needed or it was the best.
Br
On Wednesday, December 5, 2012, Rick Waldron wrote:
On Wed, Dec 5, 2012 at 10:06
On Wed, Dec 5, 2012 at 6:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
For what is worth it , I don't believe everyone does it like that has
ever been a valid argument. Maybe everyone simply copied a pattern from
jQuery without even thinking if it was needed or it was the best.
On 5 December 2012 02:46, Brendan Eich bren...@mozilla.org wrote:
Also, good luck getting SunSpider or V8/Octane to enable use strict!
Paging Dr. Rossberg on the latter :-P.
Octane actually contains two benchmarks running in strict mode, namely
PDF/JS and GameBoy. (Unfortunately, I just
and as last argument from my side, I **LOVE** the DOM appendChild method
and I use it a lot
var div = document.body.appendChild(document.createElement(div));
This is the best example of returning the value I could think and the one
I use the most on daily basis.
Br
On Wed, Dec 5, 2012 at 8:37
On Dec 5, 2012, at 8:49 AM, Andreas Rossberg rossb...@google.com wrote:
On 5 December 2012 02:46, Brendan Eich bren...@mozilla.org wrote:
Also, good luck getting SunSpider or V8/Octane to enable use strict!
Paging Dr. Rossberg on the latter :-P.
Octane actually contains two benchmarks
Le 5 déc. 2012 à 15:28, Brendan Eich bren...@mozilla.org a écrit :
Claude Pache wrote:
Le 4 déc. 2012 à 22:28, Brendan Eichbren...@mozilla.org a écrit :
Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eichbren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend
On Wed, Dec 5, 2012 at 8:52 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
and as last argument from my side, I **LOVE** the DOM appendChild method and
I use it a lot
var div = document.body.appendChild(document.createElement(div));
This is the best example of returning the value I
On Wed, Dec 5, 2012 at 11:52 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
and as last argument from my side, I **LOVE** the DOM appendChild method
and I use it a lot
var div = document.body.appendChild(document.createElement(div));
This is the best example of returning the
nope
el.appendChild(document.createElement(another)).parentNode.appendChild(document.createElement(another))
... etc
the way I use it is to add and address ... once again
var current = el.firstChild ||
el.appenChild(document.createElement(first));
^_^
On Wed, Dec 5, 2012 at 9:26 AM, Tab
On Wed, Dec 5, 2012 at 1:50 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
My 2 cents against the windmills...
I personally think returning `this` in absence of any meaningful value (and
chaining in general) is a bad pattern. Chaining leads to worse readability
(there's nothing
Dart has a cascade operator (..) [1]. That's the Right Way to do chaining.
We should watch how it goes in Dart before prematurely committing to this
iffy simulation of cascading at the API level.
- Kevin
[1]
On Wed, Dec 5, 2012 at 1:04 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Dec 5, 2012 at 1:50 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
My 2 cents against the windmills...
I personally think returning `this` in absence of any meaningful value
(and
chaining in
There were various mixed concerns, like perhaps requiring implicit
scoping of @-names to be practical in classes,
Like implicitly scoping this, super, and arguments, this would cause
problems with nested scopes. Unless the name of the class was made
part of the implicitly named scope
On Tue, Dec 4, 2012 at 1:28 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eichbren...@mozilla.org
wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible
On Tue, Dec 4, 2012 at 8:28 AM, Claus Reinke claus.rei...@talk21.comwrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far?
Nov 28 TC39 Meeting Notes:
let's summarize then:
1. ~Weak/Map#set and Set#add returns void
1.1 void as return is considered useless
2. cahinability looks like the most common pattern so those methods
should return `this`
2.1 example: return map.has(key) ? map.get(key) : map.set(key,
operation()).get(key);
forgot latter comparison with an unknown value
get the value
void: var v = generate(); map.set(key, v); return v;
this: return map.set(key, generate()).get(key);
value: return map.set(key, generate());
br
___
es-discuss mailing list
On Dec 5, 2012, at 5:45 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
After reading the spec, it is really so that
On Wed, Dec 5, 2012 at 10:04 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Dec 5, 2012 at 1:50 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
My 2 cents against the windmills...
I personally think returning `this` in absence of any meaningful value (and
chaining in general)
I think here you have more libraries authors than users, with daily basis
tasks to solve without jQuery and others ... that's why here things are
different from out there, is not about knowing more or anything, IMHO.
Said that, since as I have written no pattern blocks anyone to reach same
goals
On Wed, Dec 5, 2012 at 2:02 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
let's summarize then:
1. ~Weak/Map#set and Set#add returns void
1.1 void as return is considered useless
2. cahinability looks like the most common pattern so those methods
should return `this`
Readability or library preference aside, I still think it's bizarre that
map.set(key, val)
is analogous to
(dict[key] = val, dict)
and not to
dict[key] = val
When I'm using a fluent library like jQuery or a configuration DSL like those
in the npm packages surveyed, I can see the attraction
On Wed, Dec 5, 2012 at 3:13 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Said that, since as I have written no pattern blocks anyone to reach
same goals inline I don't even feel that strong about it, I am just saying
what would be the ideal scenario in my opinion, wondering
On Wed, Dec 5, 2012 at 3:26 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Readability or library preference aside, I still think it's bizarre that
map.set(key, val)
is analogous to
(dict[key] = val, dict)
and not to
dict[key] = val
When I'm using a fluent library like
I never said they made a decision without valid considerations, I am saying
I haven't seen any informal survey **here**, the place where theoretically
we discuss ECMAScript and its present and future.
I want believe it makes sense to keep discussing here, as it has always
been, and I don't want
On Wed, Dec 5, 2012 at 3:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I never said they made a decision without valid considerations, I am
saying I haven't seen any informal survey **here**, the place where
theoretically we discuss ECMAScript and its present and future.
I've
Allen Wirfs-Brock wrote:
On Dec 5, 2012, at 5:45 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
It is bad for two reasons:
This
Herby Vojčík wrote:
__proto__s (the ones I mentioned above). You say that when they are
changed / out-of-sync / in whatever-else-nonstandard situation, then the
authoritative source of super-constructor for the SubClass constructor
should be SubClass.prototype.__proto__.constructor (that is,
Herby Vojčík wrote:
Herby Vojčík wrote:
__proto__s (the ones I mentioned above). You say that when they are
changed / out-of-sync / in whatever-else-nonstandard situation, then the
authoritative source of super-constructor for the SubClass constructor
should be
It does not matter what Map.prototype.set returns. Almost all call sites
will ignore the return value, just like they do in every other language.
If (like me) you have strong feelings about this that are not backed by
much more than personal taste, I suggest a brisk walk. That's what I'll be
I've had a look at the changes to the modules wiki page [1]. I'm liking
the syntax changes quite a lot actually, but I have a couple of comments:
1) export ExportSpecifierSet (, ExportSpecifierSet)* ;
This rule seems too permissive. It allows strange combinations like:
export x, { y:
On 12/5/12 at 1:50 AM, jussi.kallioko...@gmail.com (Jussi
Kalliokoski) wrote:
I personally think returning `this` in absence of any meaningful value (and
chaining in general) is a bad pattern.
/lurk
I have to agree with Jussi here. Whenever I consider chaining
using the returned values
On Wed, Dec 5, 2012 at 10:33 PM, Bill Frantz fra...@pwpconsult.com wrote:
On 12/5/12 at 1:50 AM, jussi.kallioko...@gmail.com (Jussi Kalliokoski)
wrote:
I personally think returning `this` in absence of any meaningful value
(and
chaining in general) is a bad pattern.
/lurk
I have to
David Herman wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smithkhs4...@gmail.com wrote:
3) I'm just OK with as. Note that it inverts the position of the string and
the binding:
import { x } from goo;
import ga as ga;
Which makes it harder to read when you have a bunch of imports
On Dec 5, 2012, at 10:41 PM, Herby Vojčík he...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
import ga for ga;
That doesn't have any correspondence to its meaning in English.
import x from goo;
That's identical to your first suggestion.
David Herman wrote:
On Dec 5, 2012, at 10:41 PM, Herby Vojčíkhe...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
I don't. These were included to show the two syntaxes (existing from and
proposed instead-of-as grouped together; to see
I don't see why you can't treat it like this: import local accessor from
resource
import ga from ga;
If you want to import specific exports then use curlies or dot notation
import ga.foo from ga;
import { foo } from ga;
On Wed, Dec 5, 2012 at 11:05 PM, Herby Vojčík he...@mailbox.sk wrote:
On Dec 5, 2012, at 11:05 PM, Herby Vojčík he...@mailbox.sk wrote:
import x from goo;
Already taken. You can't use one syntax to mean two things.
I don't. These were included to show the two syntaxes (existing from and
proposed instead-of-as grouped together; to see how they look mixed).
On Dec 5, 2012, at 11:09 PM, Matthew Robb matthewwr...@gmail.com wrote:
I don't see why you can't treat it like this: import local accessor from
resource
import ga from ga;
We really don't want `from` to be dual-purposed to sometimes mean the whole
module itself, and sometimes extracting
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
After reading the spec, it is really so that super(...) in constructor
is in fact super.constructor(...),
David Herman wrote:
On Dec 5, 2012, at 7:16 PM, Kevin Smithkhs4...@gmail.com wrote:
1) export ExportSpecifierSet (, ExportSpecifierSet)* ;
This rule seems too permissive. It allows strange combinations like:
export x, { y: a.b.c, z }, { j, k }, * from bloop;
I think it would be
49 matches
Mail list logo
