- 1 ：デフォルトの名無しさん：2012/01/02(月) 05:16:18.29
- 《ECMAScriptを語るスレ》
1. - 概要 -
ECMA-262規格として知られる言語（通称 ECMAScript）についての利用法や言語仕様、
その他四方山話をするスレです。
Standard ECMA-262 ECMAScript Language Specification Edition 5.1 (June 2011) 標準規格（英語）
http://www.ecma-international.org/publications/standards/Ecma-262.htm
Annotated ECMAScript 5.1
http://es5.github.com/
Draft Specification for ES.next (Ecma-262 Edition 6)
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Under Translation of ECMA-262 3rd Edition (日本語訳)
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/
■前スレ
ECMAScript デス 3
http://toro.2ch.net/test/read.cgi/tech/1190160481/
■過去スレ
JavaScript デス
http://pc5.2ch.net/test/read.cgi/tech/1052273054/
ECMAScript デス 2
http://pc11.2ch.net/test/read.cgi/tech/1088298991/
- 2 ：デフォルトの名無しさん：2012/01/02(月) 05:17:18.23
- 2. - JavaScriptについて -
JavaScriptは動的Webページ作成専用言語ではありません。
このスレでは、★言語★としてのECMAScript(JavaScript、JScript等)の話題を扱います。
ブラウザ環境でのJavaScriptはWeb製作板へ。ASP、CGIなどはWebProg板へ。
●スレ違い●なレスの例
+ JavaScriptによるWebページの挙動実現に関する疑問/質問、は、
■スレ違い■です。→Web製作板へどうぞ
+ Webブラウザの動作挙動に関するの疑問/質問 は、
■スレ違い■です。→Web製作板へどうぞ
+ そのほか、Webページ作成に限定した内容の疑問/質問 は、
■スレ違い■です。→Web製作板へどうぞ
■参考■[Web製作板] + JavaScript の質問用スレッド vol.94 +
http://toro.2ch.net/test/read.cgi/hp/1325400523/
※JavaScriptが板違いと言いたい人へ
運営サイドから次のような見解が出ています。
|459 飛べない削除屋 ★ sage ：04/05/30 15:38 ID:???
|>>458
|ローカルルールにはひどく単純化されて書かれていますが、
|Javascript という言語そのものが板違いなのではありません。
|用途によって板違いかどうかを判断してください。
- 3 ：デフォルトの名無しさん：2012/01/02(月) 05:21:56.94
- 3. - 主な実装 -
Rhino (Mozilla.orgでメンテナンスされている組み込みを目的としたJava製の実装)
http://www.mozilla.org/rhino/
SpiderMonkey (同上。ただしこちらはCによる実装で、Mozilla Firefoxで採用されている)
https://developer.mozilla.org/en/SpiderMonkey
NJS (旧NGSを引き継いで開発されている独立したインタプリタ実装)
http://sourceforge.net/projects/njs/
JScript (Microsoft社による実装。WSHを介したローカルマシン用のバッチスクリプトとして使用に加え、.NETの開発言語のひとつでもある。
また、WebクライアントサイドスクリプトやASPにも利用することができる。)
http://msdn.microsoft.com/ja-jp/library/72bd815a.aspx
JScript .NET
http://msdn.microsoft.com/ja-jp/library/cc435359(v=vs.71).aspx
DMDScript (Digital Mars社による実装。Windows上で利用できるJScript置き換え的な位置づけ
スタンドアロンのインタプリタに加え、COMコンポーネントとして組み込むこともできる。)
http://www.digitalmars.com/dscript/
FESI (ECMAScript第一版に準拠したJava実装)
http://www.lugrin.ch/fesi/
DMonkey (Delphi(ObjectPascal)への組み込みを目的とした実装)
http://sourceforge.jp/projects/dmonkey/
Tamarin (Adobe から Mozilla.org に寄贈された JIT 付きの仮想マシン。
コンパイラは含まれないので、ECMAScript のソースを直接実行することはできない。)
https://wiki.mozilla.org/Tamarin
- 4 ：デフォルトの名無しさん：2012/01/02(月) 05:22:47.60
- 3の続き
KJS(KDEプロジェクトによって開発された実装)
http://api.kde.org/4.0-api/kdelibs-apidocs/kjs/html/index.html
JavaScriptCore(SafariのブラウザエンジンであるWebKitで採用されている実装で、KJSを元に改良されている)
http://trac.webkit.org/wiki/JavaScriptCore
Carakan(Opera Software ASAによって開発されOperaで採用されている実装)
http://my.opera.com/core/blog/2009/02/04/carakan
V8(GoogleによるC++実装で、Google ChromeやNode.jsなどで採用されている)
http://code.google.com/p/v8/
iv / lv5(日本人によって開発されているC++実装で、ES5.1準拠を謳う)
https://github.com/Constellation/iv/wiki/lv5
- 5 ：デフォルトの名無しさん：2012/01/02(月) 05:23:15.54
- 4. - 関連スレ -
Web上におけるクライアントサイドスクリプティングに特化した実装（通称Javascript）については
WebPrograming板などの専門スレをご利用ください。
[Web製作板] + JavaScript の質問用スレッド vol.94 +
http://toro.2ch.net/test/read.cgi/hp/1325400523/
[WebProg板] Ajaxでも語りませんか Rigel4
http://kohada.2ch.net/test/read.cgi/php/1166751613/
[プログラム板] JavaScriptスレ
http://toro.2ch.net/test/read.cgi/tech/1314333133/
- 6 ：デフォルトの名無しさん：2012/01/02(月) 05:25:46.39
- ここまでテンプレ
リンク切れの修正や実装の補足などをした
- 7 ：デフォルトの名無しさん：2012/01/02(月) 09:55:56.16
- >>1
おつ
- 8 ：デフォルトの名無しさん：2012/01/02(月) 10:00:35.85
- >>989
JSON2.jsでは普通に使われてる書き方だけどな。
まぁ一般的な書き方は(functionの方ではあるけどな。
>>996-998
今回書かれているbに対して、それらの書き方は構文的にもエラー。
しかしb = と代入式が書かれてる時点で括弧なしは構文エラーではなくなる。
つまり単独での実行を例にするのは間違ってる。
- 9 ：デフォルトの名無しさん：2012/01/02(月) 10:49:33.00
- なんで右にもtestを付けるんですか？
var test = function test() {};
- 10 ：デフォルトの名無しさん：2012/01/02(月) 12:07:04.67
- name で名前が取り出せるようになるから。
- 11 ：デフォルトの名無しさん：2012/01/02(月) 12:14:18.49
- あ、それだけなんですか。デバッグの時に多少マシになる感じなんですね。
- 12 ：デフォルトの名無しさん：2012/01/02(月) 12:15:14.56
- >>8
言語仕様を読んだこと無い奴がカドクセーとかほざいてるだけだから気にするな。
- 13 ：デフォルトの名無しさん：2012/01/02(月) 12:39:13.77
- そういう流れいらないから
- 14 ：デフォルトの名無しさん：2012/01/02(月) 12:45:04.91
- カッコを付ける習慣がある以上、納得できる理由を出さないと。ただの遠吠えになってるよ。
- 15 ：デフォルトの名無しさん：2012/01/02(月) 12:59:11.96
- お前の習慣なんてしらねーよｗ
- 16 ：think49 ◆bKk/qcAKuM ：2012/01/02(月) 19:52:15.67
- >>前スレ997
ご指摘通り、記憶違いのようでした。お騒がせしました。
>>8
なるほど…。確かに代入演算子で右辺が式であることを保証している為、式文の規定にはとらわれないですね。納得です。
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/11_Expressions.html#section-11.13
>>9
名前付き関数式は関数内のスコープに影響するので変数名を変更しても自身を参照できるようになります。
- 17 ：デフォルトの名無しさん：2012/01/02(月) 20:04:49.43
-
い-635
ちなみに、平成18年度の民主党の収支報告書だが、
電通が 690,150,988円(約6億9千万円)
博報堂が 19,425,964円 (約2千万円)
読売グループ系列(読売広告、読売メディアセンター)が 72,058,917円(約7千万円)なｗ
フライシュマンヒラードジャパンが、1974000円かｗ
フライシュマンの本社はアメリカにあって、アメリカ政界や企業のPRも担当してるユダヤ系の会社だなｗ
ここが「マニュフェスト」っていう横文字を考えたんだなｗ
そういえば、今東電と電力総連がフライシュマンを雇ってるらしいじゃないｗｗ
札束で学者ひっぱたいてテレビででたらめ言わせても年寄なんかはまだまだテレビのいうことを信じるからなｗ
- 18 ：デフォルトの名無しさん：2012/01/03(火) 12:04:33.05
- >>16
> 変数名を変更しても
「変数が別のものに束縛されても」と言いたいのかな？
- 19 ：デフォルトの名無しさん：2012/01/03(火) 13:43:44.69
- ECMAScriptの規格に「束縛」なんて用語出てこないけど、何と勘違いしちゃってるの？
- 20 ：think49 ◆bKk/qcAKuM ：2012/01/03(火) 15:09:33.38
- >>18
「束縛」はわかりませんが、http://jsfiddle.net/4ULa3/1/ の「名前付き関数式を利用するパターン」がそれです。
IE8- ではバグがあるので使えませんけどね…。
http://d.hatena.ne.jp/think49/20110521/1305959222
後学の為に「束縛」を説明(もしくは参考URLの掲示)していただけると嬉しいです。
ぐぐって何となくは理解しましたが、「変数への代入 === 束縛」なのでしょうか。
この前提が正しいと仮定して、束縛することよりも元々の変数の名前で参照できなくなることが鍵のような気がします。
- 21 ：デフォルトの名無しさん：2012/01/07(土) 01:12:09.05
- ES5になってdefineProperty()とか出来て変わったようですが
下記のコードをES5らしく書くなら、どう書いたらいいでしょうか？
var O = function (a) {
this.o = a;
};
O.prototype = {
get oooo() {
return this.o;
}
};
var o = new O('oooo!');
o.oooo;
- 22 ：デフォルトの名無しさん：2012/01/13(金) 16:46:09.65
- >>8
>JSON2.jsでは普通に使われてる書き方だけどな。
hoge = function(){}();
こういうのの話だよね？
無いぞ。どこだよ。
- 23 ：デフォルトの名無しさん：2012/01/15(日) 15:53:23.33
- >>21
var O = Object.create(null, {
o: { value: "" },
oooo: { get: function() { return this.o; } }
});
var o = Object.create(O, {
o: { value: "oooo!"}
});
- 24 ：デフォルトの名無しさん：2012/02/05(日) 21:17:08.31
- http://d.hatena.ne.jp/oogatta/20111204/1322982897
ES.nextもstrawmanもキモくね?
- 25 ：デフォルトの名無しさん：2012/02/06(月) 00:49:49.89
- Traitだけありゃいいのに最適化がうんたら
- 26 ：デフォルトの名無しさん：2012/02/23(木) 00:39:23.23
- >>24
実行コンテキストがいちいち変わるのが理解出来ないからクラスベースの
構文糖用意したつもりなんだよ。妥協点がそこだったんだろ。
ところで関数が暗黙にthisプロパティを持たなくなったのは良かったが
Function.prototype.bind(cx,args...)で引数のLIST型書きかえれるようにしたのはやめて欲しかった。
Callオブジェクトを撲滅できない以上ここら辺は積極的に隠蔽すべきだと思うんだが。
__proto__プロパティがダメでObject.define*がいい理由も根拠がわからん。
- 27 ：デフォルトの名無しさん：2012/03/07(水) 21:34:12.90
- __proto__がいいと思う理由は何?
- 28 ：デフォルトの名無しさん：2012/03/08(木) 21:27:21.83
- function Foo() {};
function Bar() {};
var f1 = new Foo();
f1.constructor === Foo.prototype.constructor; // Foo
Foo.prototype = new Bar();
var f2 = new Foo();
f2.constructor === Object.getPrototypeOf(Foo.prototype).constructor; // Bar
f1.constructor !== f2.constructor; // Foo !== Bar
Foo.prototypeの参照先が変わったのに、
なぜf1.constructorはFooを指しているんでしょうか。
- 29 ：デフォルトの名無しさん：2012/03/08(木) 23:46:27.29
- newはprototypeのコピーであって参照じゃないっしょ
- 30 ：デフォルトの名無しさん：2012/03/09(金) 02:34:50.33
- >>29
言われて本読みなおしてググってやっと理解できました。
ありがとうございます。
- 31 ：デフォルトの名無しさん：2012/03/15(木) 01:18:49.40
- ECMAScript Language Specification ECMA-262 6th Edition - DRAFT
http://people.mozilla.org/~jorendorff/es6-draft.html
読みやすくてイイ！
- 32 ：デフォルトの名無しさん：2012/03/24(土) 17:13:23.76
- JavaScriptではperlの
( $foo, $bar ) = split( /,/ );
みたいな書き方は出来ない？
（リストの左辺値）
- 33 ：デフォルトの名無しさん：2012/03/24(土) 17:13:59.06
- >>32
すんません。ECMAScriptでした。
- 34 ：デフォルトの名無しさん：2012/03/24(土) 17:53:59.26
- 実装による
以上
- 35 ：デフォルトの名無しさん：2012/03/24(土) 20:34:52.67
- >>34
仕様の話に実装で答えても…
- 36 ：デフォルトの名無しさん：2012/03/24(土) 20:38:43.62
- ES5.1までの仕様にはないかな
６以降で入れるみたいな話しがちらほら
Fxはたしか実装してた気がする
- 37 ：デフォルトの名無しさん：2012/03/25(日) 00:11:46.03
- FirefoxはJavaScript1.7で導入してて
https://developer.mozilla.org/ja/New_in_JavaScript_1.7
分割代入 (destructuring assignment) って名前がついてる
- 38 ：デフォルトの名無しさん：2012/03/25(日) 07:09:48.00
- CoffeeScript使え
- 39 ：デフォルトの名無しさん：2012/03/27(火) 14:24:18.92
- 32です。ありがとうございました。
ってことは、配列の内容を個々に変数にバラすには
1個ずつ代入するしか方法がない、ってことでしょうかね。
- 40 ：デフォルトの名無しさん：2012/03/27(火) 15:40:12.32
- だからFFでできるしCS使う手もあるっていってるじゃん
- 41 ：デフォルトの名無しさん：2012/03/27(火) 23:09:58.48
- isnt演算子のセンスのなさ
isnt = is not = is!
でよかったじゃん
- 42 ：デフォルトの名無しさん：2012/03/28(水) 09:34:12.46
- それは分かりづらいから無い
- 43 ：デフォルトの名無しさん：2012/03/28(水) 21:08:23.71
- Dだと!is
- 44 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 00:37:15.88
- >>40
ES3縛りっつー前提だもんで。
結局こんなん書きました。１個ずつ代入してることには変りはないですが。
ary2lc( [ 'yy', 'mm', 'dd' ], "2012/03/28".split("/") );
function ary2lc( to, from ) {
for( var i=0; i<to.length; i++ ) {
eval( to[i] + " = " + from[i] );
}
}
- 45 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 09:42:07.10
- CoffeeScriptはES3デスよ……
- 46 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 21:57:40.92
- >>45
すんません。よく知りませんでした。
勉強します。
- 47 ：デフォルトの名無しさん：2012/04/27(金) 12:03:13.48
- ところでes6のletとconstはふざけてんのアレ？
- 48 ：デフォルトの名無しさん：2012/04/27(金) 14:32:16.75
- letはいろんな書き方できるから？
何がどうふざけてるか書いてくれないかな
- 49 ：デフォルトの名無しさん：2012/04/27(金) 22:41:57.09
- そういう感性は俺にはなかった。
letもconstもプログラム言語にはあって然るべき機能だと思うけど。
- 50 ：デフォルトの名無しさん：2012/04/28(土) 08:03:01.79
- >>48,49
jsのブロックは見た目はブロックスコープに見えるけど言語仕様上ブロックスコープはないからブロックのセマンティックスはただの複文。
複文は複数の文を一つの文とみなすことしかやってない。var定義はプロトタイプベース言語としてのメタな文脈においてmozillaはvarバインドと呼んでるんだけど
varバインドは関数スコープで変数を束縛する。このときjsではスタックフレームもオブジェクトなのでプロトタイプベースから見ればスロット集合の実体を持ってて
ローカル変数はスタックフレームオブジェクトのスロットに束縛する。このときtry-catchの変数だけは実装上varとは別のスロット集合に束縛してスコープが別になってる。
それを仕様に取り込んだのがletでvarバインドに対してletバインドと呼んだりする。let文はその文で定義された変数はその文中のみ有効というwith文の置き換え。
let式のexpの部分は暗黙のブロックに囲まれるのでlet文の構文糖。ブロック中のlet定義は複文によって一つとみなされるので複文中の文から
letは見えるけど複文の実行が終われば他のコードからは見えなくなって結果letバインドされた変数はGCされる。
あくまでブロックスコープなんてものはなくてイメージとしてはカンマ結合(let a,=1,b=2;)みたいなもんだと思えばいい。
最新のドラフトを追ってないんで変更があるかもしれないけどes6のlet,constはdeclarationといってletバインディングされる。
es6はjsの仕様に合わせずブロックスコープを仕様にしたせいでletがブロック直下にしか置けなくなった。
letはwithの抹殺以外に旧時代のスコープを新たに作るために無名関数を使うコードを完全に置き換える目的もあったのにes6の仕様だと
let文とlet式が使えなくなってそれが直接的にできなくなった。他にもif直下にlet置けないからどんなに単独のifが短くて一行で書き
たくてもブロックで囲むコーディングルールを言語仕様が強制してしまったり、letはブロック直下以外禁止なのでforの初期化子に
置けないから本末転倒になってる。これを回避するにはforをブロックで囲んでその直下にlet定義するしかない。es5のfor-initializerが
消えたのはこれに無理やり合わせるため。
ほかにもconstがletバインドだから関数スコープじゃなくなって関数の頭で条件に応じて初期化内容を変えるのに
- 51 ：デフォルトの名無しさん：2012/04/28(土) 08:04:38.56
- function f(){
if(cond) const x=1;
print(x);//!condならundefined
}
function f2(){
if(cond){
const c=//hogehoge
}else{
const c=//fugafuga
}
//色々長い処理
print(c);//!condならfugafuga
}
がif(cond){ const x=1; print(x) }else{ const x=undefined; print(x) }かconst x cond ? 1 : undefined;と
function f2(){
if(cond){
const c=//hogehoge
//色々長い処理
print(c);
}else{
const c=//fugafuga
//色々長い処理
print(c);
}
になる。ほかにもconstは最適化のために初期化子必須になったんだけどこれは元々ある変数の初期化を伴わない定義の
デフォルトはundefined valueという仕様にesでlet文法作るときのミスで合わせられなくなったせいで未初期化の
constはundefined valueに束縛されずに2度目の代入が出来てしまうため、建前は最適化のためと言ってるけど初期化子必須に
したせいでconstの値がundefined valueになるときconst c = undefinedかconst c = void(0)としなきゃいけなくなったから
cに入る値が実行時まで遅延されて逆に最適化が難しくなってる。globalのプロパティundefinedはundefined valueじゃなくて
プロパティだから[[get]]するまで値が確定しないのとvoid(0)も[[call]]しないと確定しないのが原因。
jsの元からある仕様だとconstは初期化いらないから、しない場合はundefined valueに束縛されて定義時に値が確定して最適化出来る。
- 52 ：デフォルトの名無しさん：2012/04/28(土) 08:06:50.90
- これは最適化云々より変数の値がundefined valueになることを明確に主張するコードとしてわざとこう書くもんだった。
あとfunctionDeclarationがletバインドになったから既存の実装と全く互換性がなく関数定義をifブロックで囲むと外から見えなくなる。
#ifdefしたい時はif-elseでコード全体を囲む必要がある。#ifdefした関数使うコードがifとelseで2パスあるわけ。
es6のブロックスコープは本来はブロックスコープじゃないものをブロックスコープとして仕様にしたからコンテキスト依存になって制限のほうが多くなってるんだよ。
ecma-262は乱立する実装の最小公倍数の共通化とマシンリソースやセキュリティの都合があるから、極力実装に首突っ込まないよう
配慮されてたのに3.1派が主流になってから既存の実装と互換性がないのと最適化ばかり考えて実装の都合に制限された仕様になってるのがふざけてるって話。
nextやharmonyのbrendan eichの提案見てるとnetscape草案のjs2.0にあったのばかりだしMapやWeakMapだって3.1派が昔拒否したライブラリだし元に戻そうとしてるのは分かるよ。
仕様と実装の説明すると長いな。まあ、そういうこと。
- 53 ：デフォルトの名無しさん：2012/04/28(土) 09:54:55.97
- ガチで長いぞw
- 54 ：デフォルトの名無しさん：2012/04/28(土) 17:45:52.49
- >>50
長過ぎるのと意味が分からんところがあるけど
> このときtry-catchの変数だけは実装上varとは別のスロット集合に束縛してスコープが別になってる。
とりあえず、↑これはcatch内だけだね。
> letはブロック直下以外禁止なのでforの初期化子に
> 置けないから本末転倒になってる。これを回避するにはforをブロックで囲んでその直下にlet定義するしかない。
んなこたーない。仕様的にもちゃんと置けるよ。
他は後でつっこむ
- 55 ：デフォルトの名無しさん：2012/04/28(土) 18:55:45.44
- >>50-52"をまとめると
ブロックはスコープじゃなくて唯の複文
letはスコープ作るために導入された
letはundefined valueで初期化されない
letでundefined valueで初期化されるよえに=undefined、=void(0)などと書くと最適化されにくくなる弊害がある
ってこと？
- 56 ：デフォルトの名無しさん：2012/04/28(土) 20:34:09.47
- let文、let式がなければ
var foo = 0;
{ let foo = foo; alert(foo); }
とかではまるやつが出てくるのは目に見えてるしな
- 57 ：デフォルトの名無しさん：2012/04/28(土) 22:07:39.07
- letは色んな事出来すぎるからだめなんだよなぁ
何であんなに色んな記法を作ったのか
- 58 ：デフォルトの名無しさん：2012/04/29(日) 01:30:12.11
- >>51
> ほかにもconstは最適化のために初期化子必須になったんだけどこれは元々ある変数の初期化を伴わない定義の
constやletを初期化せずに宣言するのはバグの元だろ。どの言語でも言える事だけどローカル変数は
宣言と同時に絶対初期化するべき。
> 未初期化のconst
constは初期化必須って言っているのに、未初期化って矛盾してるぞ。その時はどんな値になってるんだ？
単純に未初期化のconstは、その時点で実行時エラーになる気がするが。
- 59 ：デフォルトの名無しさん：2012/04/29(日) 01:39:48.38
- constもletもJavaScriptの構造を理解している人に取っては必要ないものだよ
他言語メインの人がなんとなく使うときにハマるからあった方がいいねってもの
- 60 ：デフォルトの名無しさん：2012/04/29(日) 01:40:25.53
- const hoge;
hoge = "後から代入できちゃう";
ってことなんじゃねーの？
undefinedな定数にしたくて初期値省略してるのに、代入されたら台無しだよっていう
- 61 ：デフォルトの名無しさん：2012/04/29(日) 02:01:05.13
- constな変数(定数)をundefinedにする意味は全くないと思うけど、単純に未定義
って事もあるから、どっちでもいいか。
constな変数は絶対に初期化しとけって事だな。
- 62 ：デフォルトの名無しさん：2012/04/29(日) 07:14:17.62
- >>60
これってできるの?
うちのchromeさんだと出来ないんだけど
正確には代入してもconstされた値は上書きできないがエラーも出ない
＃エラー出ないのはちょっとなー
const hoge = "aaaa";
hoge = "bbb"; // ここでbbbはが返る
alert(hoge); // ここで表示されるのはaaaa
const moge;
moge = "ccc"; // ここではcccが返る
alert(moge); // ここではundefinedが返る
正直な話言語仕様的には3.1で十分で
5,6なんかはは楽にするために拡張されると解釈してる
- 63 ：デフォルトの名無しさん：2012/04/29(日) 07:56:25.15
- JavaScriptって、一見代入とかができたように見えて、実はできない、という
場合ってスルーしちゃうじゃない。昔から。
foo = "foo"
foo.bar = "baz"
alert(foo.bar) // undefined
- 64 ：デフォルトの名無しさん：2012/04/29(日) 08:00:51.12
- 何のためのstrict modeなんですかねえ
- 65 ：デフォルトの名無しさん：2012/04/29(日) 08:13:31.96
- たとえばJavaだと、参照される前に確実に1回だけ初期化される変数は、
finalだけど初期値なし、にできるけどな。
要するにundefinedってのは、名前が未定義って意味じゃなくて、初期化されてない値
（unititializeとすべき？）って意味だから、「undefinedな定数」なんて無理だから、って
ことじゃね？
- 66 ：デフォルトの名無しさん：2012/04/29(日) 08:27:47.33
- >>63
これは foo.bar にアクセスした時点で新たに String オブジェクトが生成されて
そっちの bar プロパティに代入してるだけだから、
代入が失敗しているわけではないと思う
- 67 ：デフォルトの名無しさん：2012/04/29(日) 13:19:34.99
- >>66
イミフ
- 68 ：デフォルトの名無しさん：2012/04/29(日) 13:20:57.64
- fxでも失敗するね
const hoge;
hoge = "aaaa"; // aaaa
hoge; // undefined
- 69 ：デフォルトの名無しさん：2012/04/29(日) 13:26:20.85
- >>67
仕様書を読んでみるといい
- 70 ：デフォルトの名無しさん：2012/04/29(日) 13:41:28.54
- 6ドラフトの12.2.1 Let and Const Declarations
読んだけどわからん
そんなこと書いてあるかな？
- 71 ：デフォルトの名無しさん：2012/04/29(日) 14:11:35.11
- すごくおおざっぱに説明すると、プリミティブに対してオブジェクトとして
アクセスしようとすると、オブジェクトが作られて、それに対してアクセスする、
というのが言語仕様。
だから、その作られたオブジェクトの属性として設定されるけど、そのオブジェクトに
アクセスする方法がないし、元の変数は元のプリミティブを指したままなので……
というのが >>63 で起きてること。
- 72 ：デフォルトの名無しさん：2012/04/29(日) 22:57:50.88
- ゴミな仕様だな
- 73 ：デフォルトの名無しさん：2012/04/30(月) 12:10:26.90
- 普通に例外吐いて止まってくれるだけでだいぶ助かるんだが
- 74 ：デフォルトの名無しさん：2012/04/30(月) 13:06:49.34
- strict mode + Object.sealed でおｋ
- 75 ：デフォルトの名無しさん：2012/04/30(月) 15:41:31.94
- foo.bar()
みたいな明らかに一文が終了してるときもセミコロンいるやん。
if(foo)
a+b;
みたいなコード書くヤツのほうを撲滅しろよ。
- 76 ：デフォルトの名無しさん：2012/04/30(月) 16:27:47.76
- 波括弧を必須にするだけでよかったのにな
- 77 ：デフォルトの名無しさん：2012/04/30(月) 16:59:47.58
- ;の省略とかややこしくなるだけだからいらんわ
- 78 ：デフォルトの名無しさん：2012/04/30(月) 17:09:36.40
- セミコロン省略はそこまで混乱しないだろ
- 79 ：デフォルトの名無しさん：2012/04/30(月) 18:12:22.52
- 多分シェルでも全ての行末にセミコロンを付けるような人なんだろう
- 80 ：デフォルトの名無しさん：2012/04/30(月) 21:28:42.23
- セミコロン省略はあっていい
自分も付けるか気分と見やすさと必須性で決める
基本は全く無駄な物だから付けない
- 81 ：デフォルトの名無しさん：2012/04/30(月) 22:12:51.55
- 必要ないならなくなってるよ。必要だから残ってる。
httpを使うことを考えると無くせない。
- 82 ：デフォルトの名無しさん：2012/05/01(火) 07:52:42.83
- 俺は実際全くセミコロン付けないで書けている。よって必要ない。
改行せず一行に詰め込む時にだけ必要、という主張だね。
- 83 ：デフォルトの名無しさん：2012/05/01(火) 08:48:23.26
- そんなことは言ってない
必要ないところで省略した方が逆に見栄えもよく感じられて
問題もないこともあるから省略できていいって言ってる
セミコロンは必要、だけど省略も必要
わかる？
- 84 ：デフォルトの名無しさん：2012/05/01(火) 08:57:11.06
- 省略したほうがいい場面ってどこだよ
array.filter(function(v) { return v % 2 == 0 });
みたいに関数本体が一文で済むところなら
セミコロンなしでもいいかなという気はするけど、
それ以外になんかあるか？
- 85 ：デフォルトの名無しさん：2012/05/01(火) 09:25:23.96
- 一律つけた方が法則がシンプルな分
見栄えもいいよ
セミコロンの場合実害が少ないからなくても困らないけど
- 86 ：デフォルトの名無しさん：2012/05/01(火) 09:46:43.49
- メモ帳で長いコード書くとき
カッチリしたもう変更がないだろう機械的なコードはセミコロンで固めて
個性的な変更しまくりのふわふわしたコードには付けないな
- 87 ：デフォルトの名無しさん：2012/05/01(火) 09:49:49.99
- >>84
いや、むしろそういうごちゃごちゃした１行には付けるべきだろ。
a=1
b=2+a
みたいなのには必要ない、もしくは、
a=1;b=2+a;
にする。
- 88 ：デフォルトの名無しさん：2012/05/01(火) 09:54:58.57
- >>86
こーいう、背後に哲学が感じられる使い分けが
コードから読み取れれば問題ない
無分別に一貫性なくつけたりつけなかったり
は醜いし読みにくい。
考えなさっぽさが滲みでてみっともないし。
- 89 ：デフォルトの名無しさん：2012/05/01(火) 10:28:52.18
- スマホで作ってるとセミコロン付ける付けないとインデントはかなり悩む
それはそうとMathやStringが拡張される話で今盛り上がってるのは個人的にもありがたいんだけど
数の進数やbit数に関しての拡張と現在milli秒で扱ってる範囲ををmicro秒にして欲しいんだけど
そういう話は挙がってないの？
- 90 ：デフォルトの名無しさん：2012/05/01(火) 11:54:26.69
- なんでもかんでもマイクロ秒管理したら
既存APIが遅くなるんでねーの？
- 91 ：デフォルトの名無しさん：2012/05/01(火) 12:18:42.55
- OSから取得するナノ秒までで約60bit
マイクロ秒までで約50bit
ミリ秒までで約40bit
全部64bit整数使ってるだろうから変わりないのでは？
- 92 ：デフォルトの名無しさん：2012/05/01(火) 14:11:47.69
- 非力な組み込みでもecmascript使うんだから標準で仕様化したらだめだ。
- 93 ：デフォルトの名無しさん：2012/05/01(火) 14:45:30.95
- 非力というか万が一タイマーがサポートしてないのなら０埋めで返せばいいだけじゃない？
スクロールとか描画なんかの演算とタイマー設定をもう少し正確にやりたいだけでしょ？
まあディスプレイ付きのデバイスなら今時間違いなくマイクロ秒まではサポートしてるタイマー使ってるはずだけど
- 94 ：デフォルトの名無しさん：2012/05/01(火) 18:40:05.14
- セミコロン問題は、一応プラグマのopen issueのままです。
http://wiki.ecmascript.org/doku.php?id=harmony:pragmas
- 95 ：デフォルトの名無しさん：2012/05/02(水) 00:11:18.62
- >>93
だから、ECMAScriptなんつー総本山規格じゃなくて、ディスプレイ付デバイスで動かすような実装のレベルで
何とかしてよってのが>>92なんじゃねーの。
- 96 ：デフォルトの名無しさん：2012/05/02(水) 05:02:25.84
- マイクロ秒単位のタイマは、むしろ非力な組み込みでの需要の方が大きいんじゃねーの
なんにせよ非リアルタイムな環境でのマイクロ秒タイマは
信用ならない精度になるだろ
そういう話をするとしたらQueryPerformanceCounter的な高精度カウンタを新設して
自前でポーリングしれって感じになるんじゃねえかな
- 97 ：デフォルトの名無しさん：2012/05/03(木) 08:04:21.13
- コンストラクタを呼び出すとき
applyを使って引数を配列で指定したいときがあるんだけど可能かな？
例えばコンストラクタが
var C = (function(){
var c = 0;
return function (a,b) {
this.a = a;
this.b = b;
alert([a,b,++c]);
};
})();
として、とりあえず以下はダメだった。
var o = new C.apply(null, args);
var o = new (C.apply(null, args));
var o = (new C).apply(null, args);
エラー
var o = C.apply(new C, args);
コンスタラクタが二回呼ばれる
oが返されない
var o = new C();
C.apply(o, args);
コンスタラクタが二回呼ばれる
var o = {};
C.apply(o, args);
oがCのインスタンスにならない
アイデアあったらヨロ
- 98 ：デフォルトの名無しさん：2012/05/03(木) 08:34:31.35
- >>97
Function#bind を活用してみてください。
- 99 ：デフォルトの名無しさん：2012/05/03(木) 09:00:22.22
- >>98
それじゃ無理だろ。
そもそもbindさせるオブジェクトを
これから作ろうって話な訳だし。
evalして無理やりパースするくらいじゃね？
- 100 ：デフォルトの名無しさん：2012/05/03(木) 11:47:48.86
- >>97
もともとそのコンストラクタをどう使うつもりなのか
- 101 ：デフォルトの名無しさん：2012/05/03(木) 12:58:18.91
- >>97
これがしたいんだろ？
calleeと分割代入使うか__parent__書き換えるからecma標準じゃできんぞ。
calleeはYコンビネータにして分割代入はカリー化してループ回すと出来るかもしれんがこんな所じゃ貼れんよ。
function getConstructor(){
var c = 0;
return (function ([a,b]) {
this.a = a;
this.b = b;
print([a,b,++c]);
}).bind(arguments.callee, Array.prototype.slice.call(arguments));
};
var cons = getConstructor(1,2);
var o = new cons();
- 102 ：デフォルトの名無しさん：2012/05/03(木) 13:59:28.01
- >>97
ES5仕様のbindがあるならこんなんでどうよ？
function applyNew(ctor, args) {
var a2 = [null];
a2.push.apply(a2, args);
return new (ctor.bind.apply(ctor, a2));
}
applyNew(C, [2,3]);
- 103 ：デフォルトの名無しさん：2012/05/03(木) 14:19:49.87
- それじゃapplyNewの戻り値が関数になるし[2,3]がインスタンスにバインドされない。
隠蔽したいのはCのvar c=0だけだと思う。
- 104 ：デフォルトの名無しさん：2012/05/03(木) 14:32:30.10
- いい忘れた。
a2.push.apply(a2, args)じゃなくてArray.prototype.push.apply(a2, args)じゃね？
- 105 ：デフォルトの名無しさん：2012/05/03(木) 15:32:29.16
- >>100
基本的には「コンストラクタを呼び出す時に
apply的な呼び出しは可能なのか」ということ。
限定的な使い方ではなくクロージャとかになっていても
問題ないような記法が自分では見つけられなかった。
あるコンストラクタのユーティリティ関数を作るときに
関数内からコンストラクタを呼び出す際、
引数の数が一定じゃない場合などは配列で渡せるとシンプルだなと思ったので。
強引な代替案なら思い付くんだけど
ハッとするようなスマートな記法をお持ちの方がいたら
勉強になるなと思ったですw
- 106 ：デフォルトの名無しさん：2012/05/03(木) 17:23:25.41
- >apply的な呼び出しは可能なのか
関数の仮引数を分割代入するだけだからnextが標準化されるまで待つよろし。
(function ({"a": a, "b": b}){return a+b;}).call(thisObj, {a : 1, b : 2})//->3
(function ([a,b]){return a+b;}).apply(thisObj, [1,2]);//->3
>クロージャとかになっていても
thisがレキシカルじゃないから元から出来るけどecmaが許さない。
- 107 ：デフォルトの名無しさん：2012/05/03(木) 17:54:48.87
- 言っておくが >>102 でできるからな。
- 108 ：デフォルトの名無しさん：2012/05/03(木) 20:53:52.00
- >>107
jqueryとかのbindメソッドじゃダメだよね？
現時点で実装してる処理系ってFirefoxくらい？
- 109 ：デフォルトの名無しさん：2012/05/03(木) 21:15:07.89
- ES5だからIE9以上を含む全てじゃね？
IEはしらんがFxやらGoogleChromeやらOperaは実装済のはず
- 110 ：97：2012/05/03(木) 23:41:34.06
- >>102
ありがとう！
勉強になったよ
pushの結合もオレには新しかったｗ
concatより早いんかな
あとで調べてみようっと
- 111 ：デフォルトの名無しさん：2012/05/04(金) 11:32:46.04
- 形だけなら別にbind 要らねんじゃね？
var Func = (function(){
var c = 0;
return function (a,b) {
this.a = a;
this.b = b;
alert([a,b,++c]);
};
})();
function applyNew (C, args) {
function F() {};
F.prototype = C.prototype;
var o = new F();
C.apply(o, args);
o.constructor = C;
return o;
}
var args = ["A", "B"];
var o1 = applyNew(Func, args);
var o2 = applyNew(Func, args);
var o3 = applyNew(Func, args);
alert(o1 instanceof Func)
- 112 ：デフォルトの名無しさん：2012/05/04(金) 13:43:47.26
- __proto__使わずに同じ事する懐かしの方法だな。
>>105はnew(C.apply(...))の形式が取りたいって最初の要件は良かったのか？
- 113 ：デフォルトの名無しさん：2012/05/04(金) 13:45:14.01
- 最初の要件かそもそも、不明確なので
- 114 ：デフォルトの名無しさん：2012/05/04(金) 15:36:13.38
- >>112
実引数に配列を渡したいだけかと思ってたが。
- 115 ：デフォルトの名無しさん：2012/05/04(金) 15:47:45.81
- >コンストラクタを呼び出すときapplyを使って引数を配列で指定したい
これが要件で
>として、とりあえず以下はダメだった。
>var o = new C.apply(null, args);
>var o = new (C.apply(null, args));
>var o = (new C).apply(null, args);
>コンスタラクタが二回呼ばれる
>oが返されない
>oがCのインスタンスにならない
これを解決したいって話だったが>>97
- 116 ：デフォルトの名無しさん：2012/05/04(金) 16:43:37.62
- >>115
そうか、>>111は忘れてくれw
- 117 ：デフォルトの名無しさん：2012/05/23(水) 01:38:00.11
- ECMAからES5.1仕様書のHTML版公開
http://ecma-international.org/ecma-262/5.1/
- 118 ：デフォルトの名無しさん：2012/05/23(水) 11:26:27.98
- 素晴らしい。
- 119 ：デフォルトの名無しさん：2012/06/04(月) 06:55:06.70
- お兄ちゃん、感心しているだけじゃなくてちゃんと読まないとダメだよ？
- 120 ：デフォルトの名無しさん：2012/06/04(月) 16:23:57.05
- あー毒舌な妹がこんなところにまで
- 121 ：デフォルトの名無しさん：2012/06/10(日) 04:12:22.56
- なあお前ら。
関数が結合されるのがヤダヤダ！って場合は__parent__の代わりにbind使えばいいが__proto__はどうするよ？
あと自己反映のときのcalleeとか。harmonyにProxyがあるのにcalleeがダメな理由てなんだ？
- 122 ：デフォルトの名無しさん：2012/06/10(日) 11:15:47.27
- >>121
__proto__のgetterはObject.getPrototypeOf、setterはObject.createである程度代用できる
arguments.calleeについてはhttp://togetter.com/li/215907 が参考になる
- 123 ：デフォルトの名無しさん：2012/06/11(月) 07:47:35.23
- >>122
そこ色々間違ってるから鵜呑みにしないほうがいいぞ。
- 124 ：デフォルトの名無しさん：2012/06/11(月) 10:30:16.63
- >>123
どこがどう間違っているのか分からないとあなたの情報を鵜呑みに出来ない
- 125 ：デフォルトの名無しさん：2012/06/11(月) 10:30:27.73
- >>123
ご指摘ありがとう
よろしければ、より参考になる資料を示して頂けると嬉しい
- 126 ：デフォルトの名無しさん：2012/06/14(木) 17:49:57.32
- 古い情報も相当残ってるけどwiki.ecmascript.orgが確実。
- 127 ：デフォルトの名無しさん：2012/06/14(木) 18:28:36.68
- >>126
古い情報が相当残っているのに確実とする理屈がわからない
結局、どこが間違っているかも言及なしだしあてにはできないなー
- 128 ：デフォルトの名無しさん：2012/06/15(金) 08:25:24.62
- 書いた本人は分かってるんだろうけど書き方がイマイチだから読む人がちゃんと分からないのではってことかな？
いずれにしろ１つのサイトだけあてにするのはダメ
- 129 ：デフォルトの名無しさん：2012/07/01(日) 15:23:04.66
- http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
>removed <| and TriangleLiterals
これだからTC-39はダメなんだ！
- 130 ：デフォルトの名無しさん：2012/07/01(日) 16:24:38.17
- そらそうよｗｗｗ
これでもう復活はないなｗ 嫌いじゃないけどちょっと無理がありすぎたんだｗ
- 131 ：デフォルトの名無しさん：2012/07/02(月) 11:09:20.07
- ダメなところを改善したいBrendan EichといじりたくないTC39の戦いはまだまだつづく！
- 132 ：デフォルトの名無しさん：2012/07/02(月) 13:59:41.98
- AS3が一番とばっちりだよな。
先走りすぎたせいでJS2とも別モンになっちまったしhaXeの方がJS2に近いくらいだわ。
- 133 ：デフォルトの名無しさん：2012/07/02(月) 14:57:01.97
- Q. JS2とは？
- 134 ：デフォルトの名無しさん：2012/07/02(月) 16:48:46.88
- ActionScript3は、少し先走りすぎだったし、
Mozillaに提供した実装Tamarinのコードの質が悪く、
仕様の安易な部分と合わせて、反対派を団結させてしまったね。
結局Mozilla.orgでもTamarinを利用するTraceMonkeyプロジェクトはなくなったし。
ECMAScript 4で議論された機能については、議論継続中だからいいんだけども。
- 135 ：デフォルトの名無しさん：2012/07/02(月) 17:20:57.92
- 議論継続中て言ったてこれだろ？
>Tentative addition of Class Definitions Syntax and Semantics in 13.5 based upon Maximally Minimal Strawman. NOTE-Classes do not yet have full consensus within TC39 and may not survive.
11.1.5 make super references illegal in method definitions within object literals
>removed <| and TriangleLiterals
subtypingのないjs1.xにclass definition入れたってFoo.prototype={}やObject.definePropertiesの構文糖でしかないし
1.xの延長である以上型変換が暗黙の強制型変換しかないから2.0と違ってタイプルーズで真の
structural typeでないから言語仕様の問題は解決できないだろ。HarmonyやStrawmanにある型付き前提の仕様入れる気無いだろTC39。
10年無駄にして最初ゴネたimport,exportとライブラリ強化入れただけだけどその間に
本来的に必要なのはclassじゃなくてsubtypeというのを少しでも認識させたのが唯一の功績だよ。
- 136 ：デフォルトの名無しさん：2012/07/06(金) 16:22:49.91
- ECMAScript 4に戻ってやり直すのが皆一番幸せになるわ
- 137 ：デフォルトの名無しさん：2012/07/06(金) 16:26:33.37
- つか明らかにJavaScriptの土管化が進行中な件
ウェブのC言語と言えば聞こえはいいが、要は誰も直で書きたがらないってことだからな。
そういう用途に応えるためにLLJSとか開き直ったものも出してきてるしｗ
- 138 ：デフォルトの名無しさん：2012/07/06(金) 16:31:52.47
- そして
問題点１：土管としては低効率
問題点２：土管が土管化を嫌がっていらんことするリスク
- 139 ：デフォルトの名無しさん：2012/07/07(土) 01:50:08.30
- それって土管って表現するの？
- 140 ：デフォルトの名無しさん：2012/07/07(土) 09:45:23.03
- 6の仕様を見ていると結構いい感じだな。早いとこ普及してほしいよ。一応仕様のリリースは来年らしいけど。
- 141 ：デフォルトの名無しさん：2012/09/10(月) 09:02:29.57
- >JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
>JavaScriptの土管化
- 142 ：デフォルトの名無しさん：2012/09/27(木) 00:40:57.35
- ECMAScript6にいつのまにかclassが追加されててﾜﾛﾀw
どうやら6/15のDraftに追加されたようだ。
さがしたら>>135で話題になってたけど、言ってる意味がわからん。。
ちょっと勉強するか。
- 143 ：デフォルトの名無しさん：2012/09/27(木) 01:36:15.53
- しかし仕様書を見てもよくわからんな。。
もう少し土管化するまで待つか
- 144 ：デフォルトの名無しさん：2012/09/27(木) 08:05:08.60
- 土管化が何を指してるのかさっぱりだ
- 145 ：デフォルトの名無しさん：2012/10/01(月) 02:35:37.39
- http://www.slideshare.net/agigigigi/ecmascript-study-2-esnext-updates
http://constellation.github.com/slides/contents/20120812/presentation.html
この辺りを見てclassについてある程度理解出来た。
単なるシンタックスシュガーなんだな。それで十分だ。
それにしても、モジュールの機能が無いみたいだけどそれ以外は普通にモダンな
スクリプト言語になっちゃうね。
- 146 ：デフォルトの名無しさん：2012/10/01(月) 12:03:59.01
- 言語設計は最初からモダンだけどな。
ライブラリ設計は古かったけど。(殆ど無いに等しいし)
- 147 ：デフォルトの名無しさん：2012/10/14(日) 16:38:50.03
- ECMAScriptの最新 ＝ TypeScriptなの？
- 148 ：デフォルトの名無しさん：2012/10/15(月) 00:05:30.16
- 私も興味があります
現在策定中のECMAScriptとTypeScriptの相違はどの程度なのでしょうか？
- 149 ：デフォルトの名無しさん：2012/10/15(月) 00:19:27.67
- マージされることがあるとしても、バージョン二つくらい後だろ。
クラス仕様については、ECMAScriptとほぼ同じ機能になってるな。
違いは組み込みかライブラリ化の違いくらい。
- 150 ：デフォルトの名無しさん：2012/10/15(月) 17:18:28.74
- >>149
ありがとうございます
そうなると、あと10年位掛かりそうな・・・
オプショナルな静的型付けとかジェネリックとか、次の仕様に取り込まれないかな
- 151 ：デフォルトの名無しさん：2012/10/15(月) 17:47:41.70
- ECMAScript4の失敗を忘れたのか？
そこまでやるならいっそ新しい言語にしてくれたほうがマシ
糞みたいな互換性やら名前やらとはさっさとおさらばしたいぜ
- 152 ：デフォルトの名無しさん：2012/10/15(月) 20:19:01.64
- ECMAScript4の失敗についてはよく知らないけど
TypeScriptはJavaScriptの上位互換だよ
TypeScriptのように、既存のJavaScriptが動くように仕様を拡張したら問題ないのでは？
- 153 ：デフォルトの名無しさん：2012/10/15(月) 20:43:43.76
- ECMAScript4の失敗
http://ja.wikipedia.org/wiki/ECMAScript#ECMAScript_4
http://developers.slashdot.jp/story/08/08/19/0714251/
http://news.mynavi.jp/news/2008/08/18/027/
- 154 ：デフォルトの名無しさん：2012/10/15(月) 22:08:55.95
- >>153の記事を読んでの感想。
ECMAScript 4の失敗というのは、ECMAScript 4の仕様自体の問題というよりも、
Adobe、Mozilla、Opera、Google陣営と、Microsoft、Yahoo!陣営による政治的な問題
という色彩が強いように感じた。
例えば、ECMAScript 4が決裂した2008年当時は、Microsoftは「Web標準」を軽視し、
Silverlightを普及させようとしていたのではなかったか。
つまり、当時のMicrosoftは、Silverlightを普及させるために、JavaScriptが高機能になるのを嫌った。
一方、JavaScriptの重要性を認識していたMozillaやGoogleなどは、JavaScriptを大幅に拡張したかった。
そうした各陣営の様々な政治的な思惑があって、ECMAScript 4は決裂したように思う。
しかし、今は、Microsoftも「Web標準」にシフトして、業界全体でJavaScriptの重要性に対する認識が
共有されるようになったのではないか。
Webサイトに限らず、デスクトップアプリケーションやモバイルアプリ、サーバーサイドにまで
JavaScriptが使われている。
そうした中で、JavaScriptによる開発が行いやすいよう、ECMAScript 4のような大規模な拡張が
JavaScriptには求められているし、こうした要求に異を唱える陣営は今はもういないのではないか。
だから、合意に達するのであれば、慎重かつ大胆にECMAScript 6の仕様を拡張してほしいというのが、私の考え。
- 155 ：デフォルトの名無しさん：2012/10/15(月) 22:58:57.10
- MicrosoftはMicrosoftで思惑あったと思うが、
・AdobeがActionScriptをECMAScript4にしようとしていた。
・既に広く広まったECMAScript3との互換性の問題が軽視。
古いコードをどうやって実行するのか議論が深まらないまま。
・ECMAScript4の新機能の多くがActionScriptをコピーしただけで、
入れることの是非、設計詳細部の議論が深まらないまま。
・ActionScriptの機能の多くが実装者の思いつきで設計。(Adobeの公開MLに残ってる)
・参照実装であるtamarinのコードの質の低さ。
というわけでストップになった。
ただしECMAScript4で導入されそうになった機能は捨てられたわけでなく、
多くは議論を深めてから入れる方向で考えられている。
Webの現状を考えると時間をかけるのが妥当と判断された。
それはBrandenの声明にもはっきり書かれている。
- 156 ：デフォルトの名無しさん：2012/10/15(月) 23:48:22.01
- >>155
ActionScriptはECMAScript 4を元に作られたと思っていたのですが、
実際は逆で、ActionScriptを元にECMAScript 4の仕様を決めようとしていたということでしょうか？
ECMAScript 4は2回決裂しているようなので、そこらへんの前後関係は良く分かりませんが、
少なくとも2回目の決裂に関しては、Adobeの強引さとActionScriptの出来が問題になったということですかね。
ECMAScript 6に関してはしっかり議論して合意に達してほしいですね。
便利な機能が入ることを期待しつつ、時間が掛かることをもどかしく思ったりしつつ、
末端プログラマとして、仕様策定者に期待したいです。
- 157 ：デフォルトの名無しさん：2012/10/16(火) 08:10:49.32
- >実際は逆で、ActionScriptを元にECMAScript 4の仕様を決めようとしていたということでしょうか？
ドラフトを先走って実装しただけ
- 158 ：デフォルトの名無しさん：2012/10/18(木) 19:10:41.39
- >>154
前半の陰謀論はまったく要らないな
- 159 ：デフォルトの名無しさん：2012/10/19(金) 21:05:59.32
- JavaScriptの未来？
http://brendaneich.github.com/Strange-Loop-2012/#/
- 160 ：デフォルトの名無しさん：2012/10/19(金) 21:13:28.34
- >>159
ちなみにBrendan Eichのスライド
- 161 ：デフォルトの名無しさん：2012/10/19(金) 21:25:10.17
- Brendan Eich @BrazilJS 2012 - The State of JavaScript
- 162 ：デフォルトの名無しさん：2012/10/20(土) 00:54:46.78
- typescript出たばかりなのに、No Classかよw
- 163 ：デフォルトの名無しさん：2012/11/02(金) 03:30:41.79
- tcp/ipみたく実装できてから仕様が固まるのかな
- 164 ：デフォルトの名無しさん：2012/11/14(水) 10:34:30.08
- 結果論かもしれないが、ECMAScript 4を捨てたのは明らかな失策だろう。
議論議論と、皆いつからそんなに会議好きになったのかな。
この記事がとても興味深いんだけど。
第二次世界大戦中のライフハック「仕事を進まなくさせる8ヵ条」
http://akihitok.typepad.jp/blog/2008/06/8-411f.html
> 1. 何事をするにも「通常のルート」を通して行うように主張せよ。
> 決断を早めるためのショートカットを認めるな。
> 2. 「スピーチ」を行え。できる限り頻繁に、長い話をすること。
> 長い逸話や自分の経験を持ちだして、主張のポイントを解説せよ。
> 「愛国的」な主張をちりばめることを躊躇するな。
> 3. 可能な限りの事象を委員会に持ち込み、「さらなる調査と熟考」
> を求めよ。委員会のメンバーはできるだけ多く（少なくとも5人以上）すること。
> 4. できる限り頻繁に、無関係なテーマを持ち出すこと。
> 5. 議事録や連絡用文書、決議書などにおいて、細かい言葉遣いに
> ついて議論せよ。
> 6. 以前の会議で決まったことを再び持ち出し、その妥当性について
> 改めて問い直せ。
> 7. 「警告」せよ。他の人々に「理性的」になることを求め、将来やっかいな
> 問題を引き起こさないよう、早急な決断を避けるよう主張せよ。
> 8. あらゆる決断の妥当性を問え。ある決定が自分たちの管轄にあるのか
> どうか、また組織上層部のポリシーと相反しないかどうかなどを問題にせよ。
まさにウェブ標準そのものじゃないですかね。
> 「愛国的」な主張をちりばめることを躊躇するな。
オープンウェブ（）の理想を語るとかですかね、この辺に対応するのは。
- 165 ：デフォルトの名無しさん：2012/11/14(水) 10:41:03.03
- >>159
他人事ながら心配になるのは、そのスライドが現実化するよりも
Firefoxのシェアがゼロになる方がおそらく早いってことなんだが。
StatCounter等のデータ参照。特にモバイルでシェアゼロだしな。
Googleもいつまで養ってくれるんだか。
危機感があるから、ウェブの未来だのFirefox OSだの大々的にぶちあげてるんだろうけれど。
- 166 ：デフォルトの名無しさん：2012/11/14(水) 11:55:54.29
- >>165
>Firefoxのシェアがゼロになる方がおそらく早い
StatCounterのデータをきちんと分析できればその妄想は消えるよ
http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201001-201211
今Chromeが食ってるのはIE8以前のシェアとFirefox4以前のシェアってのが一目瞭然。
過去のFirefox3.xのシェアがぶっとかったから、ブラウザ名だけの分析だとFirefoxのシェアが失われてるように見えるが
実際には、Firefox5以降のラピッドリリースに乗り換えてるFirefox信者をGoogleは全然動かせてない。
その量、WEB利用者全体の20%強……このシェアがゼロになるというなら、ちょっとその理由を教えてほしい
- 167 ：デフォルトの名無しさん：2012/11/14(水) 12:14:52.56
- ちょっと昔なら逆転不可能そうに見えたブラウザ市場をChromeがガツガツ食い込んで行ったのは
裏を返せば、どのブラウザにだってまだまだシェア伸ばすチャンスはいくらでもあるってことの証明だしな
- 168 ：デフォルトの名無しさん：2012/11/14(水) 12:25:49.32
- おまいらスレチなんで各ブラウザの専スレでやってくれないかー
- 169 ：デフォルトの名無しさん：2012/11/14(水) 12:39:10.73
- そこはブラウザの専スレじゃなくてブラウザ戦争スレに誘導だろ
- 170 ：デフォルトの名無しさん：2012/11/14(水) 17:03:47.11
- |┃三 ,ｨ, (fー–─‐- ､、
|┃. ,ｲ/〃 ヾ= 、
|┃ N ｛ ＼
|┃ ﾄ.l ヽ l
ｶﾞﾗｯ.|┃ ､ゝ丶 ,..ｨ从 |
|┃ ＼`.、_ _,. _彡’ﾉﾘ__,.ゝ、 | ／￣￣￣￣￣￣￣￣￣￣￣￣￣
|┃三 ｀ゞf‐＞ｎ;ﾊ二r^ｧｎj＜ y=ﾚヽ ＜ 話は聞かせてもらったぞ！
|┃. |fjl、 ｀￣ﾘj＾ヾ) ￣´ ﾉ ﾚ ﾘ | Operaは滅亡する！
|┃三 ヾl.`ｰ- べｌ,- ｀ ｰ-‐’ ,ン ＼＿＿＿＿＿＿＿＿＿＿＿＿
|┃ l r─‐-､ /:|
|┃三 ﾄ､ ｀二¨´ ,.ｲ |
|┃ _亅::ヽ、 .／ i :ﾄ､
|┃ -‐”｢ F′:: `:ー ‘´ ,.’ ﾌ ＞ｰ､
|┃ ﾄ､ヾ;､..__ , ‘_,.／ ／l
- 171 ：デフォルトの名無しさん：2012/11/15(木) 16:23:31.62
- >>164
かなり勘違いしてる。
>>165
これ、まだ現実味ない事ばかり書いてるわけじゃなくて、
既に確定しているversion 6や既に現実になっていることが多い。
Javascriptが共通基盤になるって話がちょっと盛ってあるくらい。
- 172 ：デフォルトの名無しさん：2012/11/22(木) 22:07:58.91
- 正直Windowsみたいに一社独占になった方が開発は楽になるけどね。
今後はいろいろなOSとブラウザが乱立するんだろうね。
- 173 ：デフォルトの名無しさん：2012/11/23(金) 08:48:10.93
- > 正直Windowsみたいに一社独占になった方が開発は楽になるけどね。
一生Adobe信者になれば楽になれるぞ
- 174 ：デフォルトの名無しさん：2012/11/23(金) 09:55:42.99
- そういやアドベはブラウザは作らないのかね。
作って普及させれば全て無駄にならないのに。
- 175 ：デフォルトの名無しさん：2012/11/23(金) 10:39:23.23
- Flashプラグインあるじゃん。これさえあれば既存の全ブラウザ乗っ取ったも同然。
- 176 ：デフォルトの名無しさん：2012/11/23(金) 16:48:28.33
- すでにIE10が乗っ取れてないわけだが
- 177 ：デフォルトの名無しさん：2012/11/24(土) 12:58:20.82
- なんかe4xが死にそう
interpolationは便利だったのに
- 178 ：デフォルトの名無しさん：2012/11/27(火) 04:47:12.84
- これか
https://developer.mozilla.org/en-US/docs/E4X
かなり思い切った決断だけど
なんで廃止にする必要があったの？
問題はFirefoxだけ？
- 179 ：デフォルトの名無しさん：2012/11/27(火) 04:50:27.92
- >>178
ごめん、E4Xをサポートしているのは、ブラウザではFirefoxぐらいか？
- 180 ：デフォルトの名無しさん：2012/11/27(火) 10:58:00.49
- もっと早くに死んでるべきものだった。
XML literal syntax(笑)
- 181 ：デフォルトの名無しさん：2012/11/27(火) 11:22:01.01
- セキュリティの問題さえなければ便利だったんだけどね
innerHTML（笑）は標準化さえされてないし、DOMは超冗長だし
- 182 ：デフォルトの名無しさん：2012/11/27(火) 15:07:03.68
- >>181
innerHTMLは標準化されてるよ
http://domparsing.spec.whatwg.org/#innerhtml
http://www.w3.org/TR/DOM-Parsing/#widl-Element-innerHTML
- 183 ：デフォルトの名無しさん：2012/11/27(火) 16:30:09.11
- E4Xってヒアドキュメントに使うもんだと思ってた
っていうかこれからヒアドキュメントどうすればいいんや・・・
- 184 ：デフォルトの名無しさん：2012/11/27(火) 17:35:53.95
- >>182
ちゃんと勧告まで進めばいいな
DOM4は大丈夫そうだけど、その関連規格はコケそうで怖い
DOMの仕様は5つもW3C Noteになった前例があるし
- 185 ：デフォルトの名無しさん：2012/11/27(火) 22:54:32.73
- >>183
http://uupaa.hatenablog.com/entry/2012/11/08/154422
- 186 ：デフォルトの名無しさん：2012/12/03(月) 09:07:26.90
- >>183
ES6 Template Strings
- 187 ：デフォルトの名無しさん：2012/12/03(月) 22:31:17.95
- >>186
何この気持ち悪い構文
普通にWYSIWYGリテラルでいいのに・・・
- 188 ：デフォルトの名無しさん：2012/12/04(火) 17:52:16.89
- Perlとシェルを合体させたような変な構文だな
- 189 ：デフォルトの名無しさん：2012/12/04(火) 17:55:27.25
- XML literalの百倍マシ。Javascriptっぽいし。
- 190 ：デフォルトの名無しさん：2012/12/09(日) 23:50:29.25
- JXONってDOMなんだな
>>186
#演算子やん
- 191 ：デフォルトの名無しさん：2013/01/01(火) 13:04:46.41
- typescriptて散々実装しねぇって駄々捏ねてたのにes4の先行実装だな。
15年早かったらes5なんてなかったのに。
- 192 ：デフォルトの名無しさん：2013/01/04(金) 01:02:18.10
- http://benvie.github.com/continuum/
ここにES6が実験出来るサイトがあった。
早速classとか試してみたらちゃんと動いた。
多重継承が出来なそうだが、ES6は出来ないのかな？
あと配列内包(List comprehension)がうまく動かん…
- 193 ：デフォルトの名無しさん：2013/01/04(金) 02:06:29.51
- trait使えばできるだろ＞多重継承
ES.nextに入ってなかったっけ？
- 194 ：デフォルトの名無しさん：2013/01/05(土) 11:47:34.88
- VBScriptでweb上の画像を取得するスクリプトをいくつか書いたのだけど、
ブラウザをIE8からFireFoxに変えたら正常に動作しなくなった。
それで結局全部Jscriptに書き換えるはめになってしまった。
WSHの動作環境はブラウザに依存するもんなんでしょうか？
画像の取得に使用したcomはWinHttp.WinHttpRequest.5.1とMSXML2.XMLHTTP3.0、
使用OSはXPです。
- 195 ：デフォルトの名無しさん：2013/01/05(土) 14:25:52.62
- バッチリ依存します。そもそも、それらのAPIは標準化されていません
OperaだろうとGoogle Chromeだろうと動かないでしょう
- 196 ：デフォルトの名無しさん：2013/01/05(土) 15:01:24.08
- >>195
ありがとう。
テキストは取得できるのに画像が取得できないという症状でした。
JScriptにしたら問題なく動作するようになりました。
しかしそのJScriptでさえ、JavaScriptの「方言」と呼ばれたりしています。
う〜む……、
現実の世界では英語が国際的に標準語の地位を固めて久しいですが、
プログラムの世界は混沌としていますね。
- 197 ：デフォルトの名無しさん：2013/01/05(土) 16:09:05.30
- そのJScriptがクソなだけだ
英語が標準語ならJScriptはラテン語だろう
- 198 ：デフォルトの名無しさん：2013/01/05(土) 19:51:42.53
- MicrosoftがJScriptとかいう謎なクソ言語を作っただけの話で、
そこまでややこしい話ではない。
とりあえずIEをメインにして開発するのをやめれば
自然とそれなりに標準に沿ったものになる
- 199 ：196：2013/01/05(土) 23:50:29.96
- >>198
移植そのものは2ヶ月ほどの作業だったのですが、
その後のデバッグにみっちり1月半かかってしまいました。
それにしても、OSは世界標準なのに、実装されているバッチスクリプトが方言って……（泣）
- 200 ：デフォルトの名無しさん：2013/01/06(日) 01:06:47.43
- MSはWeb関連では失敗続きで弱小メーカーだからね。
真に世界標準なのはOffice(Excel,Word)であって、WindowsはOfficeの抱き合わせ販売
といっても過言ではない。(過言かも…)
だから、Officeの呪縛がない個人PCだとWindowsでなくてもそれほど困らないし。
- 201 ：デフォルトの名無しさん：2013/01/06(日) 01:11:47.62
- OfficeもWineで動くから実はWindowsは全く必要ない…？
- 202 ：デフォルトの名無しさん：2013/01/06(日) 02:12:03.17
- 確かにそうだね。ただ、Webアプリが充実してくるとOSの重要性は無くなっていって
どうでもよくなりそうだね。
少なくとも会社のPCは、惰性でWindowsをずっと使っていくと思われる。
- 203 ：デフォルトの名無しさん：2013/01/08(火) 19:42:04.34
- 海外じゃ公的機関が予算削減のためにOpenOfficeを使ってるだろ
- 204 ：デフォルトの名無しさん：2013/01/09(水) 15:59:00.23
- es6どんどん糞になっていくよな
proxyとAPI強化しか要らん
どこに行こうとしてるんだ
- 205 ：デフォルトの名無しさん：2013/01/09(水) 20:30:38.50
- >>204
letとかオプション引数とか=>とかが要らないわけない。
早くES6が普及してほしい。
- 206 ：デフォルトの名無しさん：2013/01/09(水) 21:04:16.79
- たまにはremoveされた<| と TriangleLiterals のことも思い出してあげてください
- 207 ：デフォルトの名無しさん：2013/01/09(水) 23:49:59.86
- >>204
API強化はスレ違いです。
- 208 ：デフォルトの名無しさん：2013/01/10(木) 00:44:06.28
- 意味が分からん。いきなり何を言ってるんだお前は
- 209 ：デフォルトの名無しさん：2013/01/12(土) 12:43:53.73
- es6でconstが導入されるけど、functionの引数にもconst指定できればいいけど。
- 210 ：デフォルトの名無しさん：2013/01/12(土) 16:18:48.94
- const引数か、あったら便利かもな
- 211 ：デフォルトの名無しさん：2013/01/12(土) 17:18:05.69
- 逆に無いと引数が変更されるのかがわからないし、
精神衛生上よくないよね。是非ともあってほしい機能だ。
- 212 ：デフォルトの名無しさん：2013/01/12(土) 17:28:59.86
- プロパティが変更できるんじゃ意味ないだろ
- 213 ：デフォルトの名無しさん：2013/01/13(日) 09:51:30.92
- >>211
constってプロパティが変更出来るのか？
そもそも、C++みたいにconstメソッドとかの指定が無いから、
メソッドが内部を変更してしまうかも分からないね。
つうか、今一俺が仕様を分かってないな…
- 214 ：デフォルトの名無しさん：2013/01/13(日) 11:03:23.10
- 今のFirefoxに実装されてるconstは、
const指定した変数が指すオブジェクトを別のオブジェクトには変更できないけど、
const指定した変数が指すオブジェクトの中身は変更できるね
これを関数引数に指定できても意味無いな
- 215 ：デフォルトの名無しさん：2013/01/13(日) 13:09:36.12
- じゃあconstの存在意義って何よ
- 216 ：デフォルトの名無しさん：2013/01/13(日) 13:52:23.84
- constはプリミティブ型にしか意味なさそう。
オブジェクトを本当にconstにするには、Object.seal(obj)を使う必要があるんだろうね。
- 217 ：デフォルトの名無しさん：2013/01/13(日) 14:14:28.53
- インタプリタでconstは厳密な実装が難しい。ましてevalのある言語。
- 218 ：デフォルトの名無しさん：2013/01/13(日) 14:15:58.46
- >>216
オブジェクトを書き込み不可にしたいのならそう。
通常、constは参照の方の属性。
- 219 ：デフォルトの名無しさん：2013/01/13(日) 17:39:39.16
- >>217
それは違うんじゃないかな？Object.seal()とかあるわけだし。
それにしても、es6になっても癖のある言語である事に変わりないね。俺は好きだがw
- 220 ：デフォルトの名無しさん：2013/01/13(日) 17:51:08.18
- >>219
const引数修飾子はオブジェクトの属性ではないのです。
- 221 ：デフォルトの名無しさん：2013/01/13(日) 18:23:10.52
- >>220
>>217はインタプリタの一般論で言ってたから、そんなわけないとObject.seal()
を例にして否定したんだよ。
- 222 ：デフォルトの名無しさん：2013/01/13(日) 19:10:38.56
- 一部でも難しければ、全体が難しいんじゃないかな？
- 223 ：デフォルトの名無しさん：2013/01/13(日) 19:26:59.41
- じゃあどうやってObject.seal()実装してるの、って話だろ
別に一部も全部も難しくないって
- 224 ：デフォルトの名無しさん：2013/01/13(日) 19:44:05.92
- はあ?
Property descriptorで全てのpropertyをflexible: falseにして、
新規propertyを作れなくするんだけど?
- 225 ：デフォルトの名無しさん：2013/01/24(木) 19:33:48.70
- flexibleは名前変わったしsealじゃなくてfeezeだよ
インタプリタでconst難しいのはあってるけど
- 226 ：デフォルトの名無しさん：2013/02/01(金) 22:14:26.55
- 代入した時にエラーを吐くならともかく
完全にスルーするってどういう意味があるのかサッパリでござる
バグの元にしかならんと思うんだが
- 227 ：デフォルトの名無しさん：2013/02/02(土) 00:31:41.27
- そんなあなたにstrict mode
- 228 ：デフォルトの名無しさん：2013/02/03(日) 13:30:29.45
- >>226
pageをリロードしたときに二重定義エラーになるからだろ。
リロードしたときに一々コンテキスト毎再生成してたら遅いだろ。
標準化されたstrict modeはfatal-warnings modeの挙動取り込んだんだから
>>227の言う通りデバｯグのときだけstrict mode使えば良いじゃん。
それよかletになつたから#ifdefとして使えんのが痛い。
他のも標準化範囲半端だから不便だけどfor ofとextraとコレクションやっと入ったんだ喜べ！
- 229 ：デフォルトの名無しさん：2013/03/07(木) 15:27:21.75
- http://en.wikipedia.org/wiki/ABAP 112位
https://github.com/languages/Lasso 54位
https://github.com/michaelcontento/monkey マルチプラットフォームなcompilerらしいが実態は謎 108位
https://github.com/languages/MoonScript coffeeっぽい lua transpiler 107位
https://github.com/languages/Rouge ruby 実装の clojure 109位
https://github.com/languages/TypeScript 真打登場？しかしrazor-qtなぜおまランクに入ってる… 80位
https://github.com/languages/PogoScript forthっぽい js transpiler 111位
https://github.com/languages/Xtend みんなも言語つくろうね！そんなeclipseで言語dsl作成ツール 99位
githubのランクにニューフェース（新言語）登場！
上記ふたつは昔からあるのだけど。状況を一言で言い表すと
すげー混沌でこれは…っていうか百花繚乱
- 230 ：デフォルトの名無しさん：2013/03/22(金) 13:13:07.13
- JScriptから、要素数が65536の配列に見える
ｵﾌﾞｼﾞｪｸﾄをC#で作っています。
x[1]=2とか、y=x[1]と書くと、IReflect.GetFieldではなく
IReflect.GetFieldsですべてのメンバを取得してから
"1"という名前のフィールドを探しているようです。
GetFieldsを呼び出された時点では、
目的のフィールド名が分からないので
フィールド名が"0"〜"65535"のFieldInfo配列を返したら
InvokeMemberまでに数秒かかってしまいます。
要素数に関わらない時間で呼び出せるようにする
方法はありませんか?
- 231 ：デフォルトの名無しさん：2013/03/22(金) 13:18:16.69
- proxy
- 232 ：デフォルトの名無しさん：2013/03/29(金) 07:35:30.36
- https://github.com/timkurvers/byte-buffer
>Theoretically any browser supporting JavaScript's typed arrays is
>supported. Unfortunately, the spec hasn't been finalized yet and
>as such support is limited for now.
http://stackoverflow.com/tags/typed-arrays/hot
http://stackoverflow.com/tags/arraybuffer/hot
いまさらtyped-arrayとか調べてみたけどやっぱこの辺でつまったorz
よくみたらphpもasのライブラリとかも書いててすごいなオスロのひと…
- 233 ：デフォルトの名無しさん：2013/04/03(水) 13:55:55.13
- >>230
ちょうどおいらもC#でjscript等で使用されることを想定してるオブジェクトを設計してるんだけど
IExpandoとかIReflectとか実装する意味ある？(面倒くさい)
もうできること限定しちゃって
コレクションもコレクションクラス作っちゃってやったほうが楽じゃね？
x.Set( 1, 2 );
y = x.Item( 1 );
で妥協しちゃだめ？
- 234 ：230：2013/04/04(木) 12:31:59.48
- setﾒｿｯﾄﾞでは妥協したくないところです。
IReflect.InvokeMemberに"[DISPID=0]"というメンバに対する処理を書いて
x(1)=2、y=x(1)というのは実装できました。
今のところ、これ以上の策がなく、妥協してるところです。
IExpandoを実装するとx[1]=2は実装できたんですが
y=x[1]に対応しようとすると、
230に書いた課題が残るんですよ。
コレクションではなくて、UART経由で0〜65535のアドレスを持つ
レジスタへの読み書きなので、GetFieldsを呼び出された時点で
求めるメンバ名が取得できれば良いんですけどね。
- 235 ：デフォルトの名無しさん：2013/04/28(日) 12:03:49.25
- Functional JavaScript: Introducing Functional Programming with Underscore.js
http://www.amazon.com/Functional-JavaScript-Introducing-Programming-Underscore-js/dp/1449360726/
Publication Date: June 18, 2013
- 236 ：デフォルトの名無しさん：2013/04/30(火) 19:29:37.54
- es6 draft 15.4.4
>is not an Array exotic object
なん、だと・・・往生際が悪いぞ！マスター・アジア！
わざわざ下線引くからには皆考えることは同じだな。
あと、MappedArgumentsObjectがjs1.2のarguments objectと同じ仕様じゃん。caller無くした代わりか。
つか上がってるpdf3月なのにもう古い。
- 237 ：デフォルトの名無しさん：2013/05/29(水) 16:28:30.33
- 30%の確率で0、70%の確率で1を返すプログラムを教えてください
- 238 ：デフォルトの名無しさん：2013/05/29(水) 19:04:59.18
- >>237
乱数
- 239 ：デフォルトの名無しさん：2013/05/29(水) 19:14:50.60
- if ( (new Date()).getSeconds() % 3 ){
return 1;
}else{
return 0;
}
- 240 ：デフォルトの名無しさん：2013/05/29(水) 19:54:46.93
- >>239
それなら Date.getTime() % 3 の方がGC的によい
- 241 ：デフォルトの名無しさん：2013/05/29(水) 20:08:41.26
- そもそもそれ70%のコードじゃなくね
- 242 ：デフォルトの名無しさん：2013/05/30(木) 12:49:14.78
- これはひどい
- 243 ：デフォルトの名無しさん：2013/05/30(木) 14:10:10.49
- >>240
ほとんどのシステムで時計見るのは遅いよw
- 244 ：デフォルトの名無しさん：2013/06/01(土) 03:42:36.21
- >>237
課題はできた?
亀だが。
f();
とすることで取り出せるから。
上のは全然できてないから、これちゃんと提出してね。
var f = (function () {
var b = this.a,
l = b.length,
r = function (l) {
return Math.floor(Math.random() * l);
};
return b[r(l)];
}).bind(
(function (a) {
var r = [],
i = 0;
a.forEach(function (m, v) {
for (i = 0; i < m; i += 1)
r.push(v);
});
return {a: r};
}([3, 7]))
);
- 245 ：デフォルトの名無しさん：2013/06/02(日) 21:39:31.17
- >>237
var f = function() {
var base = 10000000;
var r = Math.floor(Math.random() * 10 * base);
return r < 3 * base ? 0 : 1;
};
// 検証コード
var zero = 0;
var one = 0;
for (i = 0; i < 10000000; ++i) {
var result = f();
if (result == 0) {
++zero;
}
if (result == 1) {
++one;
}
}
print(zero / (zero + one)); // => 0.2999617
print(one / (zero + one)); // => 0.7000383
- 246 ：デフォルトの名無しさん：2013/06/02(日) 21:42:53.65
- 少し間違った
var f = function() {
var base = 10000000;
var r = Math.floor(Math.random() * 10 * base + 1);
return r < 3 * base ? 0 : 1;
};
- 247 ：デフォルトの名無しさん：2013/06/04(火) 16:55:54.33
- >>244,245
↑
こいつらは何がしたいわけ？
- 248 ：デフォルトの名無しさん：2013/06/07(金) 12:17:25.74
- どっかのアホなスレと勘違いしてるんだろ
- 249 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- (function (x) {
y=2;
print(x,y);
function(x){x=10;y=20;print(x,y)};
print(x,y)})(1)
[出力]
1 2
10 20
1 20
これ一体どう実装されているんだろう？
クロージャの生成で変数テーブルの参照を共有するのだろうから
yの変更が反映されるのは至極真っ当。
xの変更が反映されないのは、引数については変数捕捉されないように細工がされている？
a.クロージャ生成時に見えていた変数テーブル
b.クロージャ引数用の変数テーブル
この２つを持っていて、変数評価時に走査している？
さらにクロージャの中でクロージャ生成する場合は
a,bを合わせて新たに1つのaにしているんだろうか。
- 250 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- >>249
単純に4行目のfunction宣言内で新しい環境が作られているからじゃね？
つまり3行目と5行目のprint呼び出しに現れるxは、
1行目のfunction宣言の環境内で束縛されているけれど、
4行目はのprint呼び出しは(新しい)別の環境内にあるx(の束縛)を参照している
- 251 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- 4行目が
function(x){x+=10;y=20;print(x,y)};
だとどうよ
- 252 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- >a,bを合わせて新たに1つのaにしているんだろうか。
スタックみたいにテーブルを重ねていくんじゃね
- 253 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- >>249
たまたま名前が同じだが以下と同じだ。
(function (x) {
y=2;
print(x,y);
function(z){z=10;y=20;print(z,y)};
print(x,y)})(1)
名前が同じだけで別のものだ。
scopeって考えを理解できてない。
- 254 ：デフォルトの名無しさん：2013/07/25(木) NY:AN:NY.AN
- >>249
出力結果おかしくない?
4行目は即時関数じゃないから、実行されないと思うんだけど。
実行環境によっては、それで実行されるのか?
それ以外は453が正解だと思うが。
- 255 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- 変数yとかzがグローバル変数だし
4行目が名前無しの関数宣言？してるだけだし
もうなんかプログラム的にめちゃくちゃ
- 256 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- zはグローバルじゃない。
- 257 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- トップレベルで束縛されている変数を「グローバル変数」と呼び、
それ以外のすべての変数を「ローカル変数」と呼ぶとすれば、
>>256が言うようにzはグローバル変数じゃないし、それどころか
>>249,253ともすべての変数がローカル変数だったりする
で、あるクロージャ(ここでは環境と同義)について、
自クロージャ内で束縛されている変数を「束縛変数」と呼び、
より外側のクロージャで束縛されている変数を「自由変数」と呼ぶとすれば、
>>249の場合
[外側のクロージャ内] x(仮引数): 束縛変数, y: 束縛変数
[内側のクロージャ内] x(仮引数): 束縛変数, y: 自由変数
>>253の場合
[外側のクロージャ内] x(仮引数): 束縛変数, y: 束縛変数
[内側のクロージャ内] x: 自由変数, y: 自由変数, z(仮引数): 束縛変数
となる
- 258 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- >>257
yはグローバル変数だぞ
- 259 ：255：2013/07/26(金) NY:AN:NY.AN
- >>256-257
ごめんzはちょっと見落としてたよ
でもyはグローバル変数だろ？
仮引数じゃなければ、varつけて宣言してない変数はトップレベルに束縛されてしまうはず
なのでyはグローバル変数じゃない？
- 260 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- 内側のクロージャの宣言はChromeとかだとエラーになるな
そもそも呼び出してないんで実行結果にまったく影響無いが
これが実行できてしまう環境ってなんなの？
- 261 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- え、関数が関数返せない処理系なんかあるの？
- 262 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- 関数が何かを返すなら少なくともreturn文が必要だな
>>249と>>253はreturnも無いし関数の戻り値も参照してないけど
- 263 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- (function(){var abc; abc=function(){};})();
(function(){function abc(){};})();
(function(){function(){};})();
firefoxもchromeも三つ目だけシンタックスエラーになるね
無名関数の定義は式の右辺値になってないとだめなのかな
関数宣言と紛らわしいからか
- 264 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- 式の右辺値とか関係無いか
関数宣言になっちゃって、その場合は無名じゃダメってことなのかね
- 265 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- SyntaxError: function statement requires a name
が出るから多分そうだね
- 266 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- IEはドキュメントモードによってはエラーにならんのか
わらえるｗ
- 267 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- wshはエラー出ないね
- 268 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- Edition 3rdしか見てないけどECMA-262の仕様的にはfunction(){function(){};}はエラー
- 269 ：デフォルトの名無しさん：2013/07/26(金) NY:AN:NY.AN
- JScriptだから(震え声)
- 270 ：デフォルトの名無しさん：2013/07/27(土) NY:AN:NY.AN
- >>249
コードが間違ってないなら結合オブジェクト実装しちゃったんだろう
- 271 ：デフォルトの名無しさん：2013/08/03(土) NY:AN:NY.AN
- どうやら、6の仕様が確定するのは今年末で、最終的にリリースされるのは来年末らしいな。
もうちょっと早くなんなかったのかね。
- 272 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- ・なぜ匿名関数呼び出しの際function(){}を括弧でくるまなければいけないのか
・なぜreturnがいるのか
ファンクショナルなことしてると助長になりすぎ
- 273 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- うが抜けた
- 274 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- うはどこに入るのか
- 275 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- 助う長
- 276 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- ・なぜ「う」がいるのか
- 277 ：デフォルトの名無しさん：2013/08/04(日) NY:AN:NY.AN
- 鵜飼のためにうは存在する。
- 278 ：デフォルトの名無しさん：2013/08/05(月) NY:AN:NY.AN
- >>272
functionの前にvoidとか ! とか適当な単項演算子を書けば
括弧でくるまなくても良くなる
- 279 ：デフォルトの名無しさん：2013/08/05(月) NY:AN:NY.AN
- ほんとにファンクショナルなことやってるなら、
function(){}を括弧でくくる必要なんてほとんど無いはずなんだけどね。
returnは面倒くさいけど。
- 280 ：デフォルトの名無しさん：2013/08/13(火) NY:AN:NY.AN
- 関数リテラル使って関数オブジェクトを複数作ると、一般的にメモリ上はどうなるんだろう。
関数オブジェクトが持つのはクロージャだけなのかコード部分(text領域)も複製されるのか。
関数リテラルによる関数複製のコストが知りたい。
- 281 ：デフォルトの名無しさん：2013/08/13(火) NY:AN:NY.AN
- ソース嫁
- 282 ：デフォルトの名無しさん：2013/08/14(水) NY:AN:NY.AN
- 実装による、としか言いようがない。そしてこのスレはスレタイによれば標準規格についてのスレ。
ただ、ひとつ言っておくなら、textというのはバイナリコードを指す用語だから、
インタプリタには基本的にはそんなものはない。
- 283 ：デフォルトの名無しさん：2013/08/14(水) NY:AN:NY.AN
- >>280
関数宣言でも最適化でインライン展開するから実装者以外が気にすることじゃないな。
ariguments.calleeが遅いとか嘘で仕様からなくしたいだけだし。
>>282
純粋なインタプリタなんて素のspidermonkeyくらいじゃね?
- 284 ：デフォルトの名無しさん：2013/08/14(水) NY:AN:NY.AN
- 素朴な通訳系実装なら構文木は共有してるし、
高度なJIT持っていれば>>283の一行目の通り。
ただシビアな要求のあるコード書いてる人は、
JITあってもプロファイル取ってあれこれやってる。
https://github.com/felixge/faster-than-c
- 285 ：デフォルトの名無しさん：2013/08/30(金) NY:AN:NY.AN
- 標準準拠でさ、関数コンテキストでDontDelete属性付けずに変数定義するの方法てないよな?
esじゃなくてもActivationオブジェクトとる方法ないけどさ。
- 286 ：デフォルトの名無しさん：2013/09/02(月) 19:24:58.91
- JavaScriptに出来ないことなんてあるわけ無いだろ
eval('var abc = 123')
delete abc //true
- 287 ：デフォルトの名無しさん：2013/09/02(月) 20:20:57.78
- このスレって思い出話しかすること無い寂れた言語スレに比べて
いくらでも話題にできることあるはずなのに過疎りすぎじゃね
- 288 ：デフォルトの名無しさん：2013/09/02(月) 21:38:39.37
- >>286
evalがあったか、忘れてた。MZ-700ばりに不可能はないな。
Variable Instantiation時にCallになきゃc(`Д´と⌒c)つ彡ヤダヤダ
じゃないけどstrict mode時には使えなさそうだ。
未修飾でdeleteするとstrict modeで例外出るしDontDelete付かないことは想定してなさそうだよね。
ここら辺つめが甘いっていうか。さすが付け焼刃のes5っていうか。
>>287
仕事で使ってる土方が言語仕様全く理解してないからこっちに用無いでしょ。
プロトタイプベースだし、動的extentのくせにレキシカルクロージャ出来るとか、
es5になってプロパティの定義(属性の指定)がsmalltalkっぽくなったとか知らん人間からはobj-cくらいキモいんじゃない？
- 289 ：デフォルトの名無しさん：2013/09/03(火) 06:57:07.17
- プロパティの削除は無くてはならないけど
トップレベル変数を削除する必要のある機械なんて皆無でしょ
所によって宣言されていたり宣言が解除されていたり出来るのは変
- 290 ：デフォルトの名無しさん：2013/09/03(火) 17:44:39.86
- >>289
静的型付け言語とかそういうのから見ればプロパティの削除どころか追加さえも変って事になるんじゃね？
- 291 ：デフォルトの名無しさん：2013/09/03(火) 20:46:39.95
- プロパティの削除は機能として無くてはならないけど
関数スコープの変数宣言の解除とか使い道がないように思うんだけど
何百行もあるような関数でならまだあるのかな
- 292 ：デフォルトの名無しさん：2013/09/04(水) 00:38:38.43
- >>289
>トップレベル変数を削除する必要のある機械なんて皆無でしょ
トップレベルの変数を削除なんて誰も言ってないだろ？strict modeで未修飾のdeleteならコンテキスト関係ないぞ。
どれのこと言ってんのか分からんから次の
>所によって宣言されていたり宣言が解除されていたり出来るのは変
が曖昧だが・・・プロパティが追加されたり削除されたりするのは動的言語では当たり前の仕組み。
当たり前である以上、議論する意味はなくない？ダックタイピングが型理論的にどういう分類になるか議論するのと同じことだろ。
- 293 ：デフォルトの名無しさん：2013/09/04(水) 00:42:34.78
- 変数はプロパティとは違うだろ
そりゃvar xはJSの内部概念的には__scope__.xだけど
- 294 ：デフォルトの名無しさん：2013/09/04(水) 01:55:53.59
- 概念じゃなくて言語仕様でVOのプロパティなんだけど。何がVOになるかは定義されてないけどVOは定義されてる。
- 295 ：デフォルトの名無しさん：2013/09/04(水) 02:32:00.91
- うん、でもプロパティとは違うから。
- 296 ：デフォルトの名無しさん：2013/09/04(水) 02:34:45.15
- うん、でもプロパティとは違うから。
- 297 ：デフォルトの名無しさん：2013/09/04(水) 03:10:06.27
- うん、でもプロパティとは違うからw
- 298 ：デフォルトの名無しさん：2013/09/04(水) 03:54:10.85
- >>289>>293>>295
>>290
想定してるパラダイムが一致してないのに、
「俺の想定するECMAScriptのパラダイムではこうだ！」
って主張しても何の意味も無いだろ。
「ECMAScriptの仕様上、
過去どう定義されていて、
過去どう解釈されていて、
現在どう定義されていて、
現在どう解釈されるべきで、
将来どう定義されるべきで、
将来どう解釈されるべきなのか」
- 299 ：デフォルトの名無しさん：2013/09/04(水) 12:16:53.34
- あーこりゃ仕様に目が眩んで現実が見えてない
- 300 ：デフォルトの名無しさん：2013/09/04(水) NY:AN:NY.AN
- >>229
http://ambroselittle.com/2013/08/31/typescript-to-be-or-not-to-be/
http://adambard.com/blog/top-github-languages-for-2013-so-far/
> 36 TypeScript 972
https://github.com/trending?l=typescript
なんとなく確認してみたけど
qupzilla と qBittorrent は typescript だったんだ
…すごくいい加減そうな集計されてそう
- 301 ：290,298：2013/09/04(水) 14:25:34.29
- >>299
いや>>289>>293>>295の人らも俺々仕様に目が眩んで現実が見えてないって話だよ。
「〜と定義・解釈されるべき」だとしても「現状〜と定義されている」事にはならんだろ。
コレで話が通じてなかったらどうにもならん。
- 302 ：デフォルトの名無しさん：2013/09/04(水) 14:35:03.70
- お前が言うな
- 303 ：デフォルトの名無しさん：2013/09/04(水) 18:17:22.98
- 近頃のエンジンは再帰を末尾最適化してくれるらしいんだけど
その最適化がどういうコードならできて、どういうコードなら妨害してしまうのか知りたい
自分たまにボードゲーム作るんだけど、
そっちではスタックオーバーフロー見なくなったけど
ちょっとしたフィボナッチで起こったりするし
まあコードの書き方が悪いんだろうけど
- 304 ：デフォルトの名無しさん：2013/09/04(水) 21:53:05.57
- ES6のArrayTypeってパフォーマンスのいい多重配列が定義できるってのはわかるんだけど、
単配列としてもアクセスできるってことなんだろうか？
var Uint8_10x10Array = new ArrayType(new ArrayType(uint8, 10), 10)
var arr = new Uint8_10x10Array()
arr[2][3] = 50
Uint8_10x10Array.storage(arr).buffer[2*10+3] //50??
- 305 ：デフォルトの名無しさん：2013/09/04(水) 22:55:04.77
- ES6サポート遅いな……
privateとか今年中に実装されんのかな
- 306 ：デフォルトの名無しさん：2013/09/05(木) 00:37:56.08
- 再来月ラストコールなのに
中身の無い項目のあるドラフトとか、議論内容見てると非常に不安になってくる
- 307 ：デフォルトの名無しさん：2013/09/05(木) 09:28:25.95
- 5.1thの和訳ってないんですか？
- 308 ：デフォルトの名無しさん：2013/09/05(木) 12:48:00.89
- 変に英文キーワードの混じった和訳のほうが読みにくいと思うよ
- 309 ：デフォルトの名無しさん：2013/09/05(木) 15:35:31.71
- >>307
一応ある（もちろん非公式・未保証）
忍者規制でURL直書きできないんで↓で：
www.webzoit.net/hp/it/internet/homepage/script/ecmascript/ecma262_51/
- 310 ：デフォルトの名無しさん：2013/09/06(金) 01:32:40.32
- 一日ぶりに来て伸びてるかと思えばなんだこれ。
>>290=298=301
あんた誰だよ。
ついでに言うとVOは名前だけEnvironment Record Specification Typesに変わってるぞ.
>>305
privateてdraft落ちてなかったっけ？
symbolがユーザー定義できなくなっただろ。
- 311 ：デフォルトの名無しさん：2013/09/06(金) 01:58:18.29
- 間違いなく採用はされる、Symbolとprivateをどうまとめるかの議論がもっと必要そうなだけ。
でもES7にしようとは誰も思ってないと思う。
HTMLのように１年毎くらいでES6.1、6.2と出る可能性がかなり高いかもしれない。
- 312 ：デフォルトの名無しさん：2013/09/06(金) 03:31:25.49
- >>310
ユーザー定義は出来るのでは
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard&s=symbol
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects
- 313 ：デフォルトの名無しさん：2013/09/06(金) 07:05:18.48
- >>312
それharmony、古い。draftが出てる。
Symbolまわりは今グドグドやっててworking draftに入ったり外れたりしてる。
- 314 ：デフォルトの名無しさん：2013/09/06(金) 07:53:24.88
- >>313だが知らんと分かりづらいな。
harmonyで提案された中から選別されてdraftになる。それが↓のCurrent Working Draftのpdfの仕様書。
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
この仕様も最新の議論が反映されてるわけじゃない。wikiは古いのも新しいのも関係なくページを残してるからそれが仕様になるとは限らんよ。
んで、だいたいharmonyの中身はes6に、漏れたのとstrawmanがes7に行く形。value objectみたいに。
基本es6はjavascript1.8.5の改良、es7はそれより上だからes7が出て初めて未来と遭遇するわけ。
- 315 ：デフォルトの名無しさん：2013/09/06(金) 09:26:15.18
- >>314
いや、今のドラフトに乗ってないことなんて百も承知なんだけど。
そうは言ってもV8には既に仮実装されてるし、早期に採用される可能性が高い。
むしろされない理由がない。話し合いが足らないだけで採用する方向では合意取れてるんだし。
この頃は機能も増えて各進行度もバラバラドラフトだけじゃ追い切れないよ。
ちゃんとコミュニティの情勢も読まなきゃ。
- 316 ：デフォルトの名無しさん：2013/09/06(金) 10:33:10.17
- ES.nextという言葉が使われだしてからもう実質Living Standardになってる
合意が取れてもドラフトに載せられるまでまとめるのが間に合わなくなりつつあるしあてにはできない
- 317 ：デフォルトの名無しさん：2013/09/06(金) 13:06:46.25
- 「あーこりゃ仕様に目が眩んで現実が見えてない」ってやつか
- 318 ：デフォルトの名無しさん：2013/09/06(金) 20:12:36.57
- Number.MAX_SAFE_INTEGERとか
2^53±1のどの値にするかやプロパティ名になにが適切かが
決まるだけでもだいぶかかったしな
- 319 ：デフォルトの名無しさん：2013/09/06(金) 21:36:06.53
- 昨今一番もてはやされてるかもしれない言語が
十年ぶりに大きく変わろうとしているのに
この過疎りようはどうにかならんのかねぇ
- 320 ：デフォルトの名無しさん：2013/09/06(金) 22:43:40.90
- ここ本スレじゃねぇし。
誰もECMAScriptなんて呼ばねぇよ。
- 321 ：デフォルトの名無しさん：2013/09/06(金) 23:06:35.21
- ここよりも盛り上がってる本スレが存在するとな！？
是非教えてもらいたいｗ
- 322 ：デフォルトの名無しさん：2013/09/07(土) 00:22:32.33
- JavaScriptで検索ぐらいしようよｗ
- 323 ：デフォルトの名無しさん：2013/09/07(土) 07:53:44.82
- http://gaslight.co/blog/does-coffeescript-have-a-future
3年くらい遅くねぇか…
- 324 ：デフォルトの名無しさん：2013/09/07(土) 13:04:21.73
- 今まではその役割も兼ねてきたがこれからはTypeScriptって言われてる
- 325 ：デフォルトの名無しさん：2013/09/07(土) 14:41:13.54
- JavaScriptで検索してもここよりもスレNo少なくて最近の書き込み数も劣ってるスレしか見つからんな
- 326 ：デフォルトの名無しさん：2013/09/07(土) 18:47:43.00
- 2ch全体ならWeb制作版の質問スレが一番賑わってるかね
- 327 ：デフォルトの名無しさん：2013/09/07(土) 19:00:27.22
- それを言うのなら、
ウェブプログラム版じゃね？
なんでプログラム板と分かれてるのか知らないけど
- 328 ：デフォルトの名無しさん：2013/09/07(土) 19:01:26.63
- いやWeb制作版だよ。
桁違いすぎるｗ
+ JavaScript の質問用スレッド vol.108 +
http://toro.2ch.net/test/read.cgi/hp/1378462421/
- 329 ：デフォルトの名無しさん：2013/09/07(土) 20:47:44.93
- 屁理屈乙
そこ質問スレだから
俺も仕方ないから底で議論したりしてるけど
本来NGだから
- 330 ：デフォルトの名無しさん：2013/09/07(土) 23:24:39.01
- [JavaScript] スクリプト言語34 [Perl,Python,PHP]
http://toro.2ch.net/test/read.cgi/tech/1367771981/
これじゃないの？
- 331 ：デフォルトの名無しさん：2013/09/08(日) 00:21:12.67
- そこは元JSerの隔離スレの残り
JSerとの衝突で一時スレが喧嘩分裂した
今は収まってて本スレはこっち
【PHP,Python】ｽｸﾘﾌﾟﾄ,ﾊﾞﾄﾙﾛﾜｲﾔﾙ37【Perl,Ruby,JS】
http://toro.2ch.net/test/read.cgi/tech/1376836047/
- 332 ：デフォルトの名無しさん：2013/09/08(日) 01:05:07.84
- 今月のミーティングでは細かくはあるけど非常によく使う部分に関わる重要な部分が決まるみたいだな
- 333 ：デフォルトの名無しさん：2013/09/08(日) 01:54:36.00
- ジェネレーター周りはこれで変更無さそう
http://domenic.me/2013/09/06/es6-iterators-generators-and-iterables/
- 334 ：デフォルトの名無しさん：2013/09/10(火) 13:52:57.70
- ES5の非常に秀逸な記事を見つけた。
このレベルは中々無い。
http://constellation.hatenablog.com/entry/20101205/1291564928
- 335 ：デフォルトの名無しさん：2013/09/11(水) 00:05:34.67
- 多分unique symbols/private namesはES6に間に合って
どちらもユーザー定義出来ると思う
- 336 ：デフォルトの名無しさん：2013/09/14(土) 02:23:58.45
- >>334
記述子使ったことない奴向けだな
- 337 ：デフォルトの名無しさん：2013/09/16(月) 23:03:46.05
- ES6のオブジェクトリテラルは面白いな
http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
- 338 ：デフォルトの名無しさん：2013/09/17(火) 04:47:04.56
- <| とか妙な記号の並び使うのはどうなのよ
- 339 ：デフォルトの名無しさん：2013/09/17(火) 12:09:02.13
- obj = { a: 1 }
obj.= { b: 2 }
obj //{ a: 1, b: 2 }
が欲しい
- 340 ：デフォルトの名無しさん：2013/09/17(火) 14:46:47.01
- 演算子も１つじゃ足りなかったら、オーバーライドしなくても２つ３つと組み合わせればいくらでも作れるのね
そう言えば細菌は主にsortで使う、-1,0,1を返す<=>演算子が提案されてたね
- 341 ：デフォルトの名無しさん：2013/09/17(火) 14:54:12.59
- んなもん大昔からPerlにあるわけだが
- 342 ：デフォルトの名無しさん：2013/09/17(火) 22:38:41.72
- harmony:proposalsのページ情報がくっそ古くて役たたねえな
配列内包は
[ x for (x of a) if (x.color === ‘blue’) ]
[ square(x) for (x of [1,2,3,4,5]) ]
[ [i,j] for (i of rows) for (j of columns) ]
じゃなくて今はこうだろ
[ for (x of a) if (x.color === ‘blue’) x ]
[ for (x of [1,2,3,4,5]) square(x) ]
[ for (i of rows) for (j of columns) [i,j] ]
http://wiki.ecmascript.org/doku.php?id=harmony:array_comprehensions
- 343 ：デフォルトの名無しさん：2013/09/18(水) 01:48:14.19
- for ofはfor each inでよかったのにって思ってるのは俺だけか？
E4Xから取り込んでソースコード互換を残して欲しかった。
- 344 ：デフォルトの名無しさん：2013/09/18(水) 02:20:20.06
- for-each-inはfor-inと同様にプロトイプも辿る
配列にも安全に使えないぽっと出のポンコツ内部イテレータもどきだったでしょ
for-ofは正真正銘の外部イテレータでES6の中核機能
月とすっぽんくらい、ほんとに全然違う
JSは汎用的な言語だからE4XはES標準に組み込まれるまではいかないだろう
- 345 ：デフォルトの名無しさん：2013/09/18(水) 02:38:35.03
- E4Xはこれで我慢して
http://wiki.ecmascript.org/doku.php?id=harmony:quasis
document.body.appendChild(dom`<span>${message}</span>`)
とか可能だと思う
- 346 ：デフォルトの名無しさん：2013/09/18(水) 06:52:13.60
- これ楽しみにしてたのに否決されたらショックだ……
https://twitter.com/domenic/status/380002233024516096
- 347 ：デフォルトの名無しさん：2013/09/18(水) 21:46:30.03
-
- 348 ：デフォルトの名無しさん：2013/09/19(木) 00:00:30.00
-
- 349 ：デフォルトの名無しさん：2013/09/19(木) 00:07:13.85
-
- 350 ：デフォルトの名無しさん：2013/09/19(木) 02:15:58.26
- >>344
いやいや、シンタックスをfor each inにしてセマンティックスをfor ofにしてくれって意味。
- 351 ：デフォルトの名無しさん：2013/09/19(木) 02:40:51.35
- 動作が違うんだからソース互換守れないじゃん
何いってんのよ
- 352 ：デフォルトの名無しさん：2013/09/19(木) 03:36:17.94
- ＜お知らせ＞
このスレの住民が引っ越してきます
http://toro.2ch.net/test/read.cgi/tech/1330477388
- 353 ：デフォルトの名無しさん：2013/09/19(木) 14:12:57.57
- DOMWorkerのTransferable objectsの仕組みをJSコアでサポートすることにより、
Workerの自由度と、将来のWorkerLikeな機能の可能性が格段に増す。
http://wiki.ecmascript.org/doku.php?id=strawman:structured_clone
これと同系統な仕様で、ES7期待の星のParallels
http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism
- 354 ：デフォルトの名無しさん：2013/09/19(木) 16:46:08.91
- ES6だと念願(?)だった配列のクローンがこんな簡単にできるのな。
a1 = [1,2,3,2,1]
a2 = [...a1] //[1,2,3,2,1]
でも現状のドラフトの仕様だとこれは配列にしか適応できない？
ここでも挙がってるがFirefoxの実装のようにいてレートしてくれる方がいいのにな。
http://esdiscuss.org/topic/set-to-array-conversions
そしたらこんな使い方もできるのに。
a3 = [...new Set(a1)] //[1,2,3] 重複排除
m1 = new Map()
m2 = new Map([...m1]) //Mapのクローン
- 355 ：デフォルトの名無しさん：2013/09/19(木) 17:54:56.39
- このスレ過疎り気味だけど
お陰で最初の方を見るとES4の分析がいろいろされてて面白いな
ES6は時間を書けるだけのものになったのか、
また行き過ぎてないかを考えるのにちょうどいい
- 356 ：デフォルトの名無しさん：2013/09/19(木) 21:08:28.43
- >>354
> ES6だと念願(?)だった配列のクローンがこんな簡単にできるのな。
え？ 適当なライブラリの関数使えば、
今でも簡単にできるんじゃね？
- 357 ：デフォルトの名無しさん：2013/09/19(木) 21:30:18.63
- たかが配列のコピーに何でライブラリ入れなきゃいけないんだってことだろｊｋ
- 358 ：デフォルトの名無しさん：2013/09/19(木) 21:34:46.29
- 配列のコピーだけでプログラムが終わることなんて無いだろ？
ライブラリを入れるだけで、配列のコピー以外も含めて圧倒的に生産性が上がる。
目的と手段を履き違えてないか？
- 359 ：デフォルトの名無しさん：2013/09/19(木) 21:52:32.75
- まあ今の仕様だと多重配列にはsliceと同じ問題があるけど
arr.slice()よりはカッコイイって事だな
イテレータブルなのを全部展開してくれれば
多重配列も一発クローンできるのにね
まあそれでもES6なら多重配列のコピーが従来よりも簡単に、且つ正確に定義できる
Array.clone = (...a) => a.map((v) => Array.isArray(v) ? Array.clone(...v) : v);
var arr2 = Array.clone(arr1);
>>358
流石にその発言はないわ
- 360 ：デフォルトの名無しさん：2013/09/19(木) 21:53:39.71
- cloneするのに一番わかり易い文法って知ってるか？
b = clone(a)
これだよ？
- 361 ：デフォルトの名無しさん：2013/09/19(木) 22:02:21.42
- 関数オーバーライドが出来ないんだからそれはない
- 362 ：デフォルトの名無しさん：2013/09/19(木) 22:04:43.18
- >>359より短く書けたｗ
更に古いブラウザにまで対応。
最強じゃね？
var _ = require('lodash');
var arr2 = _.clone(arr1);
- 363 ：デフォルトの名無しさん：2013/09/19(木) 22:14:44.01
- お前がそう思うんならそうなんだろう、お前の中ではな
- 364 ：デフォルトの名無しさん：2013/09/19(木) 22:19:46.43
- JavaScriptスレから移住してきた人にはスマンが
ここは標準仕様をメインで語るスレなのよ
ライブラリの話禁止というわけではないが
そういう話の流れじゃそもそもないのよな
- 365 ：デフォルトの名無しさん：2013/09/19(木) 22:21:49.57
- Array.isArrayがないと別コンテキストのオブジェクトが本当にArrayか見分けるのは難しいんじゃないか？
- 366 ：デフォルトの名無しさん：2013/09/19(木) 22:28:43.54
- >>359よりこっちの方が良かった
Array.clone = x => Array.isArray(x) ? x.map(Array.clone) : x;
- 367 ：デフォルトの名無しさん：2013/09/20(金) 00:41:52.37
- https://speakerdeck.com/dherman/discussion-with-tc39-about-the-semantics-of-symbols
- 368 ：デフォルトの名無しさん：2013/09/20(金) 10:58:34.35
- http://stackoverflow.com/questions/14949069/lodash-undefined-in-ie?rq=1
なんか悪いんだろうなぁ…とは思うんだけど
何が悪いんだろうなぁまではよくわからん
そういうのが多すぎる…
- 369 ：デフォルトの名無しさん：2013/09/20(金) 12:16:50.61
- TC39勢力
30% コミュニティの流れに関わる
Google
15% 基礎構文や仕様の流れに関わる
Mozilla
35% 仕様の具体的な部分に関わる
Microsoft, Apple, Intel, jQuery
20% 専門的な仕様の詳細に関わる
その他凄い人、偉い人
- 370 ：デフォルトの名無しさん：2013/09/20(金) 14:47:21.10
- TC39 ３大勢力
1/3 【ハンドル・ブレーキ】
Webを牛耳る者として、三人称視点で情報や意見を提供する、情報・管理係
Google
1/3 【エンジン・アクセル】
早期実装者及び専門家として、一人称視点で仕様を策定する、規格・運用係
Mozilla, その他凄い人、偉い人
1/3 【モーター・ギア】
企業団体として、ニ人称視点であれこれ注文する、文句・要求係
Microsoft, Apple, Intel, jQuery
- 371 ：デフォルトの名無しさん：2013/09/21(土) 01:40:27.26
- DOM Promise
http://wiki.ecmascript.org/doku.php?id=strawman:promises
が思ったより早くES標準になる？
https://twitter.com/annevk/status/380723129514876929
https://twitter.com/annevk/status/380756290147868672
DOMだけで使えるのはもったいないとは思うけど
今流行ってるからと言って、安々と仕様に入れていいものなのかね
こういうのを入れると、ライブラリや各種APIもこれに合わせて書かれるようになるだろうし
使う側も積極的にこのスタイル採用するだろうから、責任凄くあると思う
Node.jsの雰囲気を丸ごと変えてしまう力もあるかも知れないし、
FirefoxOSのアプリとか、これからの出るものに凄く影響を与えるに違いない
- 372 ：デフォルトの名無しさん：2013/09/21(土) 02:09:01.60
- >>371
Promiseならそれとほぼ同じ物が
jQuery標準でついてるし、
nodeでも使える。
- 373 ：デフォルトの名無しさん：2013/09/21(土) 02:24:09.24
- ん？だから何？
標準と標準じゃない物同列に語られてももの凄く困惑するんだけど…
- 374 ：ES6 Tips：2013/09/21(土) 02:51:46.30
- var date = new Date()
var [Y,M,D,h,m,s] = date.toLocaleString('ja-JP').match(/\d+/g)
// [2013,9,21,2,49,05]
- 375 ：デフォルトの名無しさん：2013/09/21(土) 02:53:35.32
- >>373
JavaScriptの世界では、標準ではないものも
広く使わわれている。
つまり、Promise が普通の世界に
俺達は生きているわけ。
そこに標準でPromise がきても
劇的な変化はないってこと。
> Node.jsの雰囲気を丸ごと変えてしまう力もあるかも知れないし、
> FirefoxOSのアプリとか、これからの出るものに凄く影響を与えるに違いない
標準じゃないものを使っているごく普通の人たちは
標準を待っているお前よりも未来に生きている。
劇的に変わるのは、標準を待っている人たちだけ。
- 376 ：デフォルトの名無しさん：2013/09/21(土) 03:11:51.67
- >>375
標準で無いもの(拡張)は利用する側が自分で選択できる。
標準は全ての実装が準拠しようとするため選択できない。
一つの拡張が標準になると競合する拡張が潰れたりもする。
拡張を闇雲に取り込めば標準自体が肥大化する問題も起きる。
標準に取り入れるってのは全ての環境で半強制的にそれを導入させるに等しい。
先進的であればそれで良いのであれば安定版も標準化も必要ない。
お前は標準の持つ責任を安易に考えすぎ。
…と横からレスしておく。
- 377 ：ES6 Tips：2013/09/21(土) 03:14:07.70
- その根拠のない理屈には納得出来ないな
Ajaxだって、Canvasだって、標準になる前からあったが活躍しだしたのは標準化されてから
まるで全てのPromiseとAPIが何か標準に準拠して完全に互換性があるかの様に言うが、現実はそうじゃない
そもそもDOMPromiseもESで提案されてるPromiseも、今尚仕様変更が続いてるもの
そんな中幾らかの形に切り出して、バージョンの付いた標準仕様に入れる、JS標準にするということは大きな変革
準拠先も安定度も不確かな、モジュールやプラグインに頼って下さいという段階とは比べ物にならない
- 378 ：デフォルトの名無しさん：2013/09/21(土) 03:20:55.33
- >>376
話しそれ過ぎ。
> Node.jsの雰囲気を丸ごと変えてしまう力もあるかも知れないし、
> FirefoxOSのアプリとか、これからの出るものに凄く影響を与えるに違いない
まずね。標準の世界の話だけをするというのなら、
このような、実際の開発の世界の話をしなければいいのよ。
実際の開発の世界の話なんかしなけりゃいいのに、
わざわざヤツのほうが、勝手に実際の開発の領分に侵入してきた。
だから叩き返してやったまで。
Node.jsとかFirefoxOSアプリとか、何も変わりはしない。
実際の開発では、ここらへんの問題はライブラリによって
あらかた解決してしまってるの。
だから、今更標準に入ったって、何も変わりはしないの。
標準に入ったものをすぐ使えるわけでもないしね。
- 379 ：ES6 Tips：2013/09/21(土) 03:31:49.22
- どうしても使いたい奴がプラグイン導入して個人的に使うのと、
大々的に標準に入って、さあ皆さん使ってくださいとなるのでは次元が違うぞ。
とくにJSってもうWebだけのものじゃなりつつあるし、
非同期コールバック式を緩和するためには非常に有効だけど、
本当に言語仕様に入れてメリットあるのかねという話だぞ。
お前さんの言うとおり、プラグインで十分問題が解決するんなら
標準に入れて必要以上に影響を及ぼしたり、言語の肥大化を招くよりはいいだろうってことだ。
お前さんは一体何と戦ってるんだい？
- 380 ：デフォルトの名無しさん：2013/09/21(土) 03:33:04.21
- >>379
いや、お前が何と戦っているのか知りたいんだが？
- 381 ：デフォルトの名無しさん：2013/09/21(土) 03:33:31.76
- プラグインがあるから標準いらないと言いたいのなら、意見の差はないだろう
- 382 ：デフォルトの名無しさん：2013/09/21(土) 03:35:05.06
- >>380
こっちはお前さんがよく分からんツッコミしてくるからその度に冷静に返してるだけだが？
- 383 ：デフォルトの名無しさん：2013/09/21(土) 03:37:53.11
- > Node.jsの雰囲気を丸ごと変えてしまう力もあるかも知れないし、
> FirefoxOSのアプリとか、これからの出るものに凄く影響を与えるに違いない
俺は最初から、これはありえないと言ってるだけですが？
Node.jsやFirefoxOSのアプリなどの実際の開発知らないでしょ？
- 384 ：デフォルトの名無しさん：2013/09/21(土) 03:41:04.53
- そこら辺は個人の感覚だろうからそこまでは否定しないよ。
ちなみに両方とも作ったことがあるけど、それは例えから。
これから５年も１０年も仕様に入れるべきものなのかってこと。
- 385 ：デフォルトの名無しさん：2013/09/21(土) 03:42:14.06
- >>384
根拠は？
お前の妄想？
- 386 ：デフォルトの名無しさん：2013/09/21(土) 03:51:40.78
- ホント安易に考えてんなぁコイツ
- 387 ：デフォルトの名無しさん：2013/09/21(土) 03:52:29.34
- 根拠というか懸念した理由は上でいくつか挙がってるけど、
もちろん自分が下手するとそうなりそうで怖いなと思っただけで、
標準に入ることで絶対に悪くなるとは言わない。
しかし、今更ES標準になったところで影響力は小さいという論には、今のところ納得出来ないな。
あると考えるのが基本なんだから、無いと思うのならもっと理論的に言って欲しい。
- 388 ：デフォルトの名無しさん：2013/09/21(土) 03:58:25.22
- > しかし、今更ES標準になったところで影響力は小さいという論には、今のところ納得出来ないな。
歴史が証明している。
ECMAScript 5が標準になってどんな影響があったか？
明らかに小さいだろう？
- 389 ：デフォルトの名無しさん：2013/09/21(土) 04:00:26.96
- あ、非JSerはお帰りください
- 390 ：デフォルトの名無しさん：2013/09/21(土) 04:03:17.56
- 理論的な話ねぇ？
ES標準になっても、すぐに使えるわけではない。
使わないから影響を与えられない。
ES非標準で、ライブラリとして実装できるものは
すでに実装され使われている。
十分理論的ですね。
- 391 ：デフォルトの名無しさん：2013/09/21(土) 04:03:22.79
- お前らが最近プログラム系の板によく現れる荒らしに構ってる間にも
仕様はどんどん勧告へと近づいてきてる
https://twitter.com/BoazSender/status/381129573804417024/
- 392 ：デフォルトの名無しさん：2013/09/21(土) 04:04:42.74
- うん、、、もういいよ。
お前さんに分かってもらうのは諦めた。
- 393 ：デフォルトの名無しさん：2013/09/21(土) 04:43:03.51
- >>390が日本語読めない子なのは十分わかった
けど俺も標準に入れてもいいとは思うぞ
ただしC++11のoptional featureみたいな感じがベストじゃないか。すべての標準処理系がDOMを備えるべきだとは思えんし
- 394 ：デフォルトの名無しさん：2013/09/21(土) 04:52:47.89
- utilモジュールに入れてimportで取ってくる形ならいいけど、
グローバルにむき出しなら嫌だな
- 395 ：デフォルトの名無しさん：2013/09/21(土) 05:02:38.84
- ポイントは前倒ししてまでstrawmanをES6に入れるのかってとこじゃね？
入れるのなら今回のミーティングがラストチャンスだけど
ギリギリで間に合わせた感もあるしな
http://esdiscuss.org/topic/promises-final-steps
ライブラリと違って、JSの規格に一度入ると後方互換性を壊す変更は当然NGになるしね
もうちょっとWebでの使われ方見てから練っても十分な気がする
やっぱりいろいろとES6.1が必要なんじゃないかな
というかこの冬のラストコールに間に合うの？
- 396 ：デフォルトの名無しさん：2013/09/21(土) 05:46:24.50
- >>371,395
PromiseLoveなAnne van Kesterenっていう人が早く入れようとしてるように見える
- 397 ：デフォルトの名無しさん：2013/09/21(土) 21:13:19.03
- http://tc39wiki.calculist.org/es6/
>ES6 reached "proposal freeze" in May, 2011: no new major proposals can be added,
>although proposals can still be removed. TC39 is targeting a release date of December, 2013
>for the official ES6 standard, but JS engines are implementing individual features
>before the spec is finalized.
策定は2011年度の５月にfreezeとあるが…
ECMAScript Support Matrix
http://pointedears.de/scripts/test/es-matrix/
各実装のマトリックス表らしい
http://mozilla.6506.n7.nabble.com/Promises-final-steps-td290303.html
スレを眺めてるとES7とか文字が並んでるし議論してる人らは
ES6のことを念頭に置いて話てる訳ではないんでないの
- 398 ：デフォルトの名無しさん：2013/09/21(土) 23:48:12.67
- ミーティングに挙げる仕様を詰めてるだけでES6には入れようとしてないよ
今回はES7についても話し合われたからね
- 399 ：デフォルトの名無しさん：2013/09/21(土) 23:59:44.55
- 読むとDOM PromiseのJS実装版じゃなくて、
もっと低レベルな感覚な実装なのね、いいかも。
でもこれ入れるんなら、
イベントという概念をもっとJSから扱えやすくなって欲しいな
そっちの方向の進化はかなり良さそう
- 400 ：デフォルトの名無しさん：2013/09/22(日) 00:16:25.61
- イベントはあまりに重要で各環境の事情を抱えた概念だから難しそう
イベントキューの操作くらいは一般化出来ないかな？
- 401 ：デフォルトの名無しさん：2013/09/23(月) 13:42:34.69
- 今話題になってるこのコードとても面白いね
仕様の奥深くまで分かってないとできないことだ
Array.apply(null, { length: 5 }).map(Number.call, Number);
// [0, 1, 2, 3, 4]
- 402 ：デフォルトの名無しさん：2013/09/25(水) 01:26:27.21
- https://github.com/rwaldron/tc39-notes/tree/master/es6/2013-09
なかなか興味深い……
ArrowFunctionが残念だなあ
Symbol周りは期待通りになってよかった
Moduleはもう少し精査が必要だね
ES7についても見えてきた
- 403 ：デフォルトの名無しさん：2013/09/27(金) 01:13:04.58
- ECMAScript6に単純に型指定だけ出来て、静的型チェックしてくれれば最強なのに…
型指定以外は完全に一緒で良いんで、そういうプリプロセッサを誰か作ってくれないかな。
- 404 ：デフォルトの名無しさん：2013/09/27(金) 01:54:42.52
- あー、7のguardsがそれにあたるのか。7がリリースされるのっていつになるやら…
- 405 ：デフォルトの名無しさん：2013/09/28(土) 07:44:14.08
- http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#september_27_2013_draft_rev_19
- 406 ：デフォルトの名無しさん：2013/10/04(金) 12:32:46.81
- ES6ファミリーにPromiseが入ります。
おめでとう・・・・・・・・！ おめでとう・・・・・・・・！
- 407 ：デフォルトの名無しさん：2013/10/05(土) 18:32:39.18
- ES7のdata_parallelismがFirefox 27 (Nightly) でデフォルトで有効になったようだ。
http://jsperf.com/array-intersection-filter-vs-for-loop/2
http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism
- 408 ：デフォルトの名無しさん：2013/10/07(月) 19:50:12.74
- isRegExpシンボルって面白いね
String.prototype.match(regexp)
はregexpオブジェクトに@@isRegExpが合った時には
rx.match(this)
を呼ぶことになってる
つまりオレオレ正規表現が容易に実装できるってことか
class MyRegExp {
constructor( ...... ) { ...... }
match(string) { ...... }
replace(string, replaceValue) {......}
split(string, limit) {......}
}
let regexp = new MyRegExp( ...... );
string.match(regexp);
string.replace(regexp, replaceValue);
string.split(regexp, limit);
- 409 ：デフォルトの名無しさん：2013/10/13(日) 16:05:28.76
- ES6概要
ただしこれでも仕様の半分程度
https://speakerdeck.com/simonenko/ecmascript-6-budushchieie-javascript
- 410 ：デフォルトの名無しさん：2013/10/16(水) 01:04:25.93
- asm.js、32bit浮動小数点演算、SIMD演算の現状と可能性について
http://kripken.github.io/mloc_emscripten_talk/sloop.html
- 411 ：デフォルトの名無しさん：2013/10/19(土) 19:00:16.23
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ParallelArray
- 412 ：デフォルトの名無しさん：2013/10/24(木) 16:53:52.96
- ecma262.info/
ECMA-262 Edition 5.1に相当するISO/IEC 16262:2011の仕様は、
日本のSC22専門委員会でJIS規格化されないことが決定されたため、
ECMA-262 Edition 5.1の公的な日本語訳は存在しないことになります。
- 413 ：デフォルトの名無しさん：2013/10/24(木) 19:47:18.44
- は？ ISO規格に追随するのやめちゃったの？
C++11も翻訳しないみたいだし、JISCは馬鹿なの？死ぬの？
- 414 ：デフォルトの名無しさん：2013/10/24(木) 20:16:16.20
- 本文は翻訳してないあのスタイルじゃあ、あっても無いのとたいして変わりなかったしなw
- 415 ：デフォルトの名無しさん：2013/10/25(金) 01:44:56.49
- つーか規格の和訳って必要ないよなぁ
どうせ原文にあたらなきゃならくなるんだから
- 416 ：デフォルトの名無しさん：2013/10/25(金) 02:50:16.91
- JISにすることで著作権フリーになるんだよ（適当）
- 417 ：デフォルトの名無しさん：2013/10/25(金) 10:55:39.28
- 昔は日立とか東芝とか三菱とかが
主要言語のマイコンパイラ作ってたから、
社内技術者のために日本語訳が欲しいという要求があったけど、
今は業界からそういう要望もないのでしょう。
エコシステムとか言うんでしょ。
- 418 ：デフォルトの名無しさん：2013/10/25(金) 15:38:22.47
- >>416
なるなら大歓迎だわ。
ぜんぜんなんねーんだよ。
- 419 ：デフォルトの名無しさん：2013/10/25(金) 16:29:14.50
- エコシステム->生態系
- 420 ：デフォルトの名無しさん：2013/10/25(金) 16:39:32.81
- >>418
実質著作権フリーだぞ。規格表さえ手に入れればあとはネットに上げようと何しようと自由。
http://urheberrecht.cocolog-nifty.com/blog/2009/07/18jis-2372.html
http://urheberrecht.cocolog-nifty.com/blog/2010/06/45jis-be6d.html
ただ、判例としてあるのは類似のドイツのものだけで、日本での判例はまだないけどね
- 421 ：デフォルトの名無しさん：2013/10/25(金) 16:56:58.44
- JISの著作権は原案作成者とそれを規格化の過程において修正する工業調査会にあり、
公衆送信権は工業調査会が独占している。
- 422 ：デフォルトの名無しさん：2013/10/25(金) 17:02:49.30
- >>416
原文嫁
著作権は放棄しないって明記されてるぞ
- 423 ：デフォルトの名無しさん：2013/10/25(金) 17:07:45.39
- 著作権は内国法優先だから、日本で規格の著作者やISOがどんなに著作権を主張しようと
著作権法の第13条第2号がある限り著作権が認められるはずがない……ってのが>>420のリンク先の主張でしょ
自分も法律を字義的に解釈すればそれであってると思うけど、これ以上は著作権スレに行ってやったほうがいいね
- 424 ：デフォルトの名無しさん：2013/10/25(金) 17:31:57.94
- 規格書は告示、訓令、通達その他これらに類するものじゃないから。
「XXXという規格を制定した」これは告示、XXXの規格書本体は告示じゃない。
- 425 ：デフォルトの名無しさん：2013/10/25(金) 18:01:00.17
- >>424
だからその屁理屈はドイツじゃ通らなかったんだっつーの
- 426 ：デフォルトの名無しさん：2013/10/25(金) 18:03:42.08
- ドイツだけじゃない。アメリカでも国の策定する規格に著作権は認められなかった。
スレチだけどな！
- 427 ：デフォルトの名無しさん：2013/10/25(金) 18:59:00.70
- >>426
>>420は公衆送信権に違反して他人の著作物を公開したいDQNのタワゴトじゃん。
ドイツでは法文に従って判断すると著作権が認められないという判決が出たから著作権法改訂されたと、当のDQNのブログにある。
- 428 ：デフォルトの名無しさん：2013/10/25(金) 19:13:55.99
- 天気の配信とか、役人の天下り先確保のために法令を整備してたでしょ。
それと同じなんじゃない？
- 429 ：デフォルトの名無しさん：2013/10/25(金) 19:19:17.04
- 分かりやすく産業にすると
・ドイツやアメリカでは国家規格に著作権は認められなかった（現在は法を改正済）
・日本は現在ドイツやアメリカの法改正前と同じ状況
・改正しないとJISに著作権は認められない
・JISスレか著作権スレでやれ
- 430 ：デフォルトの名無しさん：2013/10/25(金) 19:39:41.50
- ×・改正しないとJISに著作権は認められない
○・改正しないとJISに著作権は認められないとDQNは考えている、行政はそのように考えていない、司法が行政の不利になる判決を出すことは稀
- 431 ：デフォルトの名無しさん：2013/10/25(金) 20:17:49.62
- まあ、日本での前例もないみたいだし、これ以上水かけ論やりたいなら余所でね
- 432 ：デフォルトの名無しさん：2013/10/26(土) 10:38:18.25
- 仕様の話をしようぜ
- 433 ：デフォルトの名無しさん：2013/10/27(日) 20:35:34.71
- ECMAScript Support Matrix
http://pointedears.de/scripts/test/es-matrix/
合間合間に実装の話もですね…
- 434 ：デフォルトの名無しさん：2013/10/28(月) 09:40:22.02
- 話題出していっていいのよ
- 435 ：デフォルトの名無しさん：2013/10/30(水) 21:43:23.98
- ES7の機能で一番早く使えるようになるのはSIMDかもな
SMが来年中に実装しそうな勢いだし、何と言ってもV8が興味持ってる
影響範囲がほぼ無いしね
- 436 ：デフォルトの名無しさん：2013/10/31(木) 01:05:58.42
- double以外の数値型の演算をどうするかの話が詰まっていきそうだな
http://esdiscuss.org/topic/proposal-for-efficient-64-bit-arithmetic-without-value-objects
この様子だとES7は３年後くらいかもな
- 437 ：デフォルトの名無しさん：2013/10/31(木) 01:11:49.51
- 今はもういつES7か？ってのに
こだわる必要はない気がする。
なぜなら順次実装されて言ってるから。
完成する前に使えるようになってる。
- 438 ：デフォルトの名無しさん：2013/10/31(木) 01:35:06.64
- とは言え勧告前のものはいくら実装されていても
いつケチが付いて仕様が変わるとも知れないからな
http://esdiscuss.org/topic/math-sign-vs-0
- 439 ：デフォルトの名無しさん：2013/11/06(水) 10:03:34.97
- http://html5experts.jp/cssradar/3176/
ここのServiceWorkerとAnimation-Proxy見ると、
ES7のdata parallelismとかが思い出されて
JSerがマルチスレッド処理を当たり前に書く時代もそう遠くないんだろうね
- 440 ：デフォルトの名無しさん：2013/11/10(日) 04:10:55.98
- >>439
データ並列からマルチスレッドには飛躍があるけどな。
- 441 ：デフォルトの名無しさん：2013/11/10(日) 12:52:20.30
- は？
マルチスレッド⊃並列だろうに
どこに飛躍が？？？
- 442 ：デフォルトの名無しさん：2013/11/11(月) 14:42:38.63
- ぴょーん！
- 443 ：デフォルトの名無しさん：2013/11/13(水) 23:20:03.54
- マルチスレッドでないデータ並列がSIMD
- 444 ：デフォルトの名無しさん：2013/11/14(木) 10:57:15.41
- SIMDはそもそも並列とか意識できなくね
- 445 ：デフォルトの名無しさん：2013/11/14(木) 19:08:10.11
- 君はそうなのだろう。
- 446 ：デフォルトの名無しさん：2013/11/14(木) 19:23:39.42
- SIMDAPIを使っても必ずSIMD命令が使われるわけじゃないしあってると思うよ
- 447 ：デフォルトの名無しさん：2013/11/17(日) 15:42:20.11
- Dartのcascade演算子JSにも欲しいなあ
obj..a = 1
..b = 2
..c = 3
↓
obj.a = 1, obj.b = 2, obj.c = 3
or
Object.mixin(obj, {
a: 1,
b: 2,
c: 3
})
- 448 ：デフォルトの名無しさん：2013/11/18(月) 21:00:01.72
- いよいよ始まるというのにこの過疎りようは悲しい……
- 449 ：デフォルトの名無しさん：2013/11/19(火) 19:24:22.27
- 今が一番盛り上がる時期なのにな
- 450 ：デフォルトの名無しさん：2013/11/19(火) 22:43:24.98
- >>447
VBのWithステートメントに似ているな。
With Label
.Height = 2000
.Width = 2000
.Caption = "Label"
End With
JavaScriptのwithはピリオドが要らないという失敗をしてしまった。
with(label) {
height = 2000
width = 2000
caption = "Label"
}
たったこれだけのことだが、heightはlabel.heightなのか
withの外にあるheightなのか見た目でわからない上に、
label.heightが存在すればlabel.heightに、存在しなければwithの外のheightに
書き込むというだめだこりゃ的な動きをしてしまう。
- 451 ：デフォルトの名無しさん：2013/11/20(水) 01:28:33.20
- もしかしてプロキシと組み合わせればなんとかなる可能性が微レ存……？
function makeSafeScope(obj){
return new Proxy(obj, {
......
})
}
with(makeSafeScope(obj)) {
}
- 452 ：デフォルトの名無しさん：2013/11/20(水) 02:16:17.48
- withってこうやって使うもんでしょ
var scopeOrContext = {a:0, f: function(){++this.a}}
with(Object.create(scopeOrContext)){
f()// 1
}
scope.a// 0
- 453 ：デフォルトの名無しさん：2013/11/20(水) 03:22:46.52
- with(obj) {
a = 1
}
ってした時にaがobj.aなのかそうでないのか分かりにくいってことだよ
- 454 ：デフォルトの名無しさん：2013/11/20(水) 17:17:17.01
- そう言えば今までブロック文中の関数宣言は非推奨だったけど
ES6からはブロックスコープになったんだよな
(function (){
"use strict"
if(1){
function a() {}
}
return typeof a
})() //"undefined"
- 455 ：デフォルトの名無しさん：2013/11/21(木) 22:19:07.88
- >>401
>Array.apply(null, { length: 5 }).map(Number.call, Number);
配列内包ってもう固まったんだっけ？
- 456 ：デフォルトの名無しさん：2013/11/22(金) 00:22:59.64
- 固まってる
for-ofとifだけ
a = [1,2,3,4,5]
b = [ for(v of a) if(v > 2) v*2 ] // [6,8,10]
- 457 ：デフォルトの名無しさん：2013/11/22(金) 01:34:53.19
- ES6への機能追加が21日で完了しました。
つまり、まもなくラストコールです。
今後は約１年間、実装からのフィードバックを含めた、
バグフィックスや小規模な改定のみが行われ、勧告となります。
- 458 ：デフォルトの名無しさん：2013/11/22(金) 02:38:13.10
- やっと、ラストコールか。ちょっと停滞気味のRhinoフォークしてくる。
- 459 ：デフォルトの名無しさん：2013/11/22(金) 03:00:22.47
- え、Rhinoって使ってる人いるの？
- 460 ：デフォルトの名無しさん：2013/11/22(金) 04:24:06.17
- ググると結構あるぞ。むしろjavaだと他に何がある？
- 461 ：デフォルトの名無しさん：2013/11/23(土) 08:45:11.30
- つNashorn
- 462 ：デフォルトの名無しさん：2013/11/24(日) 16:57:20.57
- 余計な記法増やして読みにくくするのやめてほしいわ
このスレ見ても結局
黒魔術が増えるだけなんだなES6って
- 463 ：デフォルトの名無しさん：2013/11/25(月) 09:34:48.99
- 流れについていけない守旧派の極みだな
別にいいんだよ、IE6が理解できる範囲のJavascriptしか頭に入りませんってなら
- 464 ：デフォルトの名無しさん：2013/12/01(日) 04:26:34.11
- ES6は必要な進化だろうけど、そのうち黒魔術化するでしょ
LLJS/asm.js最適化しながら手書きできる人間なんて僅かしかいなくてコンパイラにjavascript吐かせる時代になるかもしれない
アセンブラやCやってた連中が復活するかもしれないけど
- 465 ：デフォルトの名無しさん：2013/12/01(日) 10:59:57.81
- Dartのことですね
- 466 ：デフォルトの名無しさん：2013/12/03(火) 12:22:46.92
- ES6が糞過ぎて猫様もお怒り
Hearing about ES6 modules - Node.js Reactions
http://nodejsreactions.tumblr.com/post/64587440442/hearing-about-es6-modules
- 467 ：デフォルトの名無しさん：2013/12/03(火) 22:17:04.57
- 猫かわいい
- 468 ：デフォルトの名無しさん：2013/12/12(木) 02:15:57.94
- http://en.wikipedia.org/wiki/ECMAScript#Conformance_tests
ここの結果見るとIEが一番準拠しててFirefoxの準拠度がダントツ悪い
逆だと思ってたから意外だな
Firefoxは仕様が決まる前から先行実装してるっていうのがあるから
しょうがない面もあるかも
- 469 ：デフォルトの名無しさん：2013/12/21(土) 19:49:07.41
- ES6はCと違ってよくわからないって人がごねた結果だろ
- 470 ：デフォルトの名無しさん：2013/12/21(土) 19:50:05.91
- >>469
Cをよくわかってないなら喋らない方がいいよｗ
- 471 ：デフォルトの名無しさん：2013/12/26(木) 23:29:54.06
- A=フェラチオ
B=手マン
C=セックス
D=スカトロ
- 472 ：デフォルトの名無しさん：2013/12/26(木) 23:57:34.24
- >>468
最新のIEと10年前のFirefoxを比較すれば当然そうなります
- 473 ：デフォルトの名無しさん：2013/12/27(金) 00:10:24.18
- 10年前にFirefoxなんかあったっけ？
10年前だとIE以外は生まれてすらいない時代だと思うけど。
- 474 ：デフォルトの名無しさん：2013/12/27(金) 00:13:04.22
- >>473
でたらめを書かないでください。
Firefoxは10年前既にありました。
- 475 ：デフォルトの名無しさん：2013/12/27(金) 00:15:25.39
- あ、やっぱりなかったみたいだね。
http://ja.wikipedia.org/wiki/Mozilla_Firefox%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%89%E9%81%B7
2003年5月16日 製品名を Firebird へ改称
2004年2月9日 製品名を Firefox へ改称
- 476 ：デフォルトの名無しさん：2013/12/27(金) 00:16:20.89
- >>473
板違い
IEの話はドザ板でやれ
- 477 ：デフォルトの名無しさん：2013/12/27(金) 00:19:58.37
- >>475
Firefoxの最初のバージョンはフェニックスと呼ばれました。
ウィキペディアで調べてもわからないことはあるものです。
そんなに恥ずかしがらなくてもいいです。
生きている価値が無いというほどのことではありません。
でも、ウィキペディアで調べて知ったかぶりをするのはもうやめたほうが良いかもしれませんね。
- 478 ：デフォルトの名無しさん：2013/12/27(金) 00:20:55.81
- 間違えた。IEを持ちだしたのは>>472だった。
>>472は消えろ
- 479 ：デフォルトの名無しさん：2013/12/27(金) 00:22:18.40
- >>475
名前が変わったら別の製品だと思ったのか
恥ずかしすぎﾜﾛﾀ
- 480 ：デフォルトの名無しさん：2013/12/27(金) 00:45:26.15
- もうそろそろ興奮収まったかい？
- 481 ：デフォルトの名無しさん：2013/12/27(金) 01:03:00.89
- ワールドクラスの馬鹿を発見した興奮！
- 482 ：デフォルトの名無しさん：2013/12/27(金) 01:05:50.54
- まだだったか
- 483 ：デフォルトの名無しさん：2013/12/27(金) 05:30:34.81
- >>477>>479
全く読んでないから知らんけど、名前が違う頃のFirefox使ったデータならその頃の名前で書くんじゃねーの？
- 484 ：デフォルトの名無しさん：2013/12/30(月) 16:38:13.73
- >>472
＞最新のIEと10年前のFirefoxを比較
どーゆー意味？
>>468に載ってるFirefoxのバージョンは26とNightly 29なんだけど
- 485 ：デフォルトの名無しさん：2013/12/30(月) 19:17:26.11
- >>468
mozilla.orgのJavascriptは独自仕様だよ。
ECMAScriptに入ってないのも独自の判断で仕様に入れて
Javascript 1.xと称している。
この場合のJavascriptはmozillaの商標。
一般的に言ってるJavascriptは標準規格のECMAScriptの通称。
そのうち独自仕様は辞めると思うが、
もともとJavascriptは彼ら（前身のNetscape社）のもの。
- 486 ：デフォルトの名無しさん：2013/12/30(月) 19:33:25.23
- 困るんだよねー
ちゃんと規格としてかっちり決まってから実装始めてもらわないと
- 487 ：デフォルトの名無しさん：2013/12/30(月) 23:27:24.32
- しかし実装がないと規格も決まらないというジレンマ
- 488 ：デフォルトの名無しさん：2013/12/31(火) 16:53:03.28
- >>486
このスレの住民の言葉とは思えんな
Fxのお陰でどれだけ仕様が改善できて策定がスムーズに行ったことだか
特に構文レベルだと長いフィードバックが不可欠
それをFxがずっと前からやってくれたおかげで、
今のFxの独自実装が抱える多くの問題を踏まずにすんだ
ChromeにだってSymbolやPromiseやら先行実装たくさんあるし
これから先もSIMDやParallelやら先行実装が重要なものは沢山ある
- 489 ：デフォルトの名無しさん：2013/12/31(火) 18:11:09.61
- これからのJSって便利にもなるが厄介なことも増えるよな
例えばnewが要るかどうか
理屈としては継承のために@@createを呼び出させるべきかどうかなんだろうけど、
Mapなんかは付けないとエラー、Proxyやvalue object系には付けるとエラー、とか覚えるのが増えるね
- 490 ：デフォルトの名無しさん：2014/01/01(水) 00:01:49.39
- 今年はES6の年です
皆さん祝いましょう！
- 491 ：デフォルトの名無しさん：2014/01/01(水) 01:43:16.27
- お断りします
- 492 ：デフォルトの名無しさん：2014/01/01(水) 02:31:16.08
- >>489
今でもフレームワークごとに違うじゃん。
- 493 ：デフォルトの名無しさん：2014/01/01(水) 10:06:51.50
- ビルドインオブジェクトの話でしょ
フレームワークはフレームワーク
まあ余談だけどユーザー側で作るAPIは基本的に
Class.initとかClass.create〜とかを提供する形にした方がいいと思うね
- 494 ：デフォルトの名無しさん：2014/01/01(水) 10:19:14.82
- ついにJSも世代が分かれて古い方はstaticおじさんと呼ばれるようになるに違いない
- 495 ：デフォルトの名無しさん：2014/01/01(水) 12:44:58.45
- ES6が糞過ぎるからしょうがないね
- 496 ：デフォルトの名無しさん：2014/01/01(水) 14:35:09.29
- そうか？物によっては10年もかけただけあって随分洗練されてると思うが
今でも微妙な問題は残ってるけど大山は全て乗り越えた感じだ
- 497 ：デフォルトの名無しさん：2014/01/01(水) 14:44:38.39
- おまえらArray.prototype.shuffleとか作ってないか？
そういうのは困るからArray.prototype._shuffleみたいにしろとさ
- 498 ：デフォルトの名無しさん：2014/01/01(水) 14:56:37.99
- ES6に足りないものは、
{obj1,obj2,obj3}.prop.{prop1,prop2,prop3}.prop = val
というシンタックス。あとはいい。
- 499 ：デフォルトの名無しさん：2014/01/01(水) 15:03:07.14
- イラネ
なんだその黒魔術
- 500 ：デフォルトの名無しさん：2014/01/01(水) 15:21:41.51
- これが黒魔術なら分割代入も黒魔術ということになってしまうな
- 501 ：デフォルトの名無しさん：2014/01/01(水) 15:30:34.13
- そうか
本当は
[a,b,c] = [1,2,3]
のように
[o.a,o.b,o.c] = [1,2,3]
を
o[a,b,c] = [1,2,3]
と書きたいが
これだとa,b,cのコンマが独立した演算子と取られてしまうから
可能性としては
o{a,b,c} = {a:1,b:2,c:3}
か
o{0:a,1:b,2:c} = [1,2,3]
とするしかないのか
それがどうも冴えないから入らなかったんだろうね
- 502 ：デフォルトの名無しさん：2014/01/01(水) 15:49:11.00
- はあ・・
JavaScript ES6 Bad Parts -分かりにくい悪手法-
という良書が出来るのが目に見えてる
- 503 ：デフォルトの名無しさん：2014/01/01(水) 15:55:16.38
- でも>>498の「{}.」は案外凄い良いシンタックスだと思うよ
{obj1,obj2,obj3}.prop.{prop1,prop2,prop3}.prop = val
{obj1,obj2,obj3}.{prop.{prop1,prop2,prop3}.prop} = val
{obj1,obj2,obj3}.{prop.{prop1,prop2,prop3}}.prop = val
{{obj1,obj2,obj3}.{prop.{prop1,prop2,prop3}}}.prop = val
読みやすさは最悪だか汎用性レベルは最高
あらゆるパターンを記述できるわ
案外ES7くらいで採用されるかもね
- 504 ：デフォルトの名無しさん：2014/01/01(水) 16:14:52.51
- ES6のBest Partsのspread演算子様
arr.slice()
↓
[...arr]
arr.slice().push(x), arr
↓
[...arr, x]
for(var i = 0, arr = []; i < len; i++) arr[i] = i
↓
arr = [...Array(len).keys()]
arr.filter(function (x, i, a) {return a.indexOf(x) == i})
↓
[...new Set(arr)]
str.split('')
↓
[...str]
可能性は無限大
- 505 ：デフォルトの名無しさん：2014/01/01(水) 16:47:20.67
- 配列内包も素晴らしい
s1 = 'abcde', s2 = '12345'
for (var arr = [], i1 = 0; i1 < s1.length; i1++) for (var i2 = 0; i2 < s2.length; i2++) arr.push(s1[i1] + s2[i2])
↓
arr = [for (c1 of s1) for (c2 of s2) c1 + c2]
- 506 ：デフォルトの名無しさん：2014/01/01(水) 21:58:18.62
- みんなcoffeescriptからの流用なんだけどね
- 507 ：デフォルトの名無しさん：2014/01/01(水) 22:56:47.56
- いいえPythonやHaskellなんかからの導入です
CSも同じく
- 508 ：デフォルトの名無しさん：2014/01/02(木) 08:45:45.32
- 他の言語からの取り入れを悪いことのように言う傾向が今年は滅びますように
- 509 ：デフォルトの名無しさん：2014/01/02(木) 10:23:18.50
- そんなのは見たことないな
- 510 ：デフォルトの名無しさん：2014/01/02(木) 10:48:29.19
- >>501
o['a', 'b', 'c'] = [1, 2, 3];
が既存の分割代入に近くていい気がする。
- 511 ：デフォルトの名無しさん：2014/01/02(木) 14:05:42.56
- プロパティの分割代入とか、プロトタイプ継承を理解していない証拠
- 512 ：デフォルトの名無しさん：2014/01/02(木) 14:27:08.28
- >>510
それは無理
o['a', 'b', 'c'] = [1, 2, 3];
は既に
o['c'] = [1, 2, 3];
と解釈されるから
- 513 ：デフォルトの名無しさん：2014/01/02(木) 16:59:30.82
- 慣れれば読みやすい可能性が微レ存
p{a,b} = q
↓
p.a = q.a
p.b = q.b
p.x.{a,b} = q
↓
p.x.a = q.a
p.x.b = q.b
p.{x.{a,b}} = q
↓
p.{x.a,x.b} = q
↓
p.x.a = q.x.a
p.x.b = q.x.b
- 514 ：デフォルトの名無しさん：2014/01/02(木) 17:00:13.11
- p.{x,y}.{a.b} = q
↓
p.x.a = q.a
p.x.b = q.b
p.y.a = q.a
p.y.b = q.b
p.{{x,y}.{a.b}} = q
↓
p.{x.a,x.b,y.a,y.b} = q
↓
p.x.a = q.x.a
p.x.b = q.x.b
p.y.a = q.y.a
p.y.b = q.y.b
p.{z:{x,y}.{c:a.d:b}} = q
↓
p.{z.c:x.a,z.d:x.b,z.c:y.a,z.d:y.b} = q
↓
p.x.a = q.z.c
p.x.b = q.z.d
p.y.a = q.z.c
p.y.b = q.z.d
- 515 ：デフォルトの名無しさん：2014/01/02(木) 17:19:12.05
- 後は分割代入でも先送りになったけど
undefinedを見逃す?演算子系は実際必要だな
if(a&&a.b&&a.b.c)
↓
if(a.?b.?c)
var {a:{b:c}} = {} //c=undefind.b -> error
↓
var {a:{?b:c}} = {} //c=undefind.?b -> undefined
- 516 ：デフォルトの名無しさん：2014/01/02(木) 17:59:53.93
- >>514
パターンマッチはスクリプト言語なら強化して欲しいが、
これに？演算子やguardやら入ったらカオスになるんだろうな。
- 517 ：デフォルトの名無しさん：2014/01/07(火) 14:42:38.41
- おまえらみんなwithでも使ってろ
ただし最後はちゃんと"use strict";を書いてデバッグすること
- 518 ：デフォルトの名無しさん：2014/01/09(木) 16:12:01.04
- with分も捨てたもんじゃない
プロキシと組み合わせればスクリプトを分かりやすく書けたりする
unit1.on('reqestCommand', unit => {
with (new ControlerProxy(unit)) {
if (Y > 100) TURN_LEFT_180
GO_100
if (Y < 0) FREEZE
}
})
- 519 ：デフォルトの名無しさん：2014/01/15(水) 00:39:55.46
- try { (ﾉ°□°）ノノ ┻━┻ } catch() { ┬─┬ ノ( ゜-゜ノ) }
- 520 ：デフォルトの名無しさん：2014/01/16(木) 20:32:57.94
- es6にguardsが入らなかったのはかなり残念だ
JavaScriptでちゃんと静的型チェックをしようとすると、
https://developers.google.com/closure/compiler/docs/js-for-compiler?hl=ja
このClosure Compilerのアノテーションを使うのが一番良さそうだけど
見ただけでめげた…
guardsの構文を受け付けて、コンパイル時に削除してくれればいいんだけどなぁ
- 521 ：デフォルトの名無しさん：2014/01/17(金) 06:08:12.57
- ES6にGuardsが入ると思ってたのはあんただけだろうが、そもそもJavaScriptに静的型チェックなんて必要ない
スクリプト言語の性格や既存のライブラリを考えると徒労に終わるだけだし
そういうことで今では::構文もbindに取られてるし、ESメンバーにもそんなに好かれていない
http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
http://esdiscuss.org/topic/value-objects-roll-your-own#content-4
Trademarksはパターンマッチの為の機能として残るだろうが、今後型のための構文が採用されることはない
JSでどうしても型を明記したい場合は、a = b|0 や c = float32(d + e) のようにすることだね
そうじゃないのを望むならDartからでも変換すればいい
- 522 ：デフォルトの名無しさん：2014/01/17(金) 10:11:32.27
- 静的型チェックっていうと大袈裟だったかもしれないけど、他人が書いた関数で
引き数に何を渡せばいいか分からない事ってないか？
複数人で規模の大きめのアプリを作る時とかは、みんなまじめにアノテーション
とか書いてんのかね。
しかしBrendan Eichがいらねってんなら望み薄だな…
bindはいいけど、guardsはTypeScriptと同じように:一個にすればいいんじゃね？
- 523 ：デフォルトの名無しさん：2014/01/17(金) 10:35:50.16
- まあダックタイピング＋トライ・アンド・エラーで行くしかしょうが無いでしょ。
公式で用意されてる関数は適当に叩けば適切なエラーが帰ってくるからそれ見習ってもいいかもな。
crypto.getRandomValues()
//TypeError: Failed to execute 'getRandomValues' on 'Crypto': 1 argument required, but only 0 present.
crypto.getRandomValues("^_^")
//TypeError: Failed to execute 'getRandomValues' on 'Crypto': First argument is not an ArrayBufferView
crypto.getRandomValues(new Float64Array(10))
//TypeMismatchError: Failed to execute 'getRandomValues' on 'Crypto': The provided ArrayBufferView is of type 'Float64', which is not an integer array type.
crypto.getRandomValues(new Int32Array(10))
//[519742316, 1326690367, 1843628936, 94818381, 1481545681, -949200701, 1818462933, -1973550051, 2019705203, -1026601786]
- 524 ：デフォルトの名無しさん：2014/01/17(金) 14:41:15.55
- トライ・アンド・エラーで別に構わないけど、crypto.getRandomValues()みたいに
適切なエラーを出す為にもGaurdsは必要だと思うけどね。
現状の現実的な解は、関数の先頭に型チェックするassertなりを仕込んでおいて
リリース時にスクリプトで削除するか、何もしない関数に置き換えるとかかな。
- 525 ：デフォルトの名無しさん：2014/01/18(土) 09:06:28.46
- Gaurdsに頼る形だとtry-catchを使うことになるし、結局型に合わなかったことしか分からない
必要なのは適切な型か、適切なインターフェイスを備えてるかをテストすることだと思う
この辺りを良くする仕組みはES6にも入ってる
ES6ではinstanceof演算子は実質オーバーライド可能になって、関数じゃないオブジェクトに対しても使えるようになった
例えばこう書ける
const IntegerArray = {
[Symbol.hasInstance](x) {
return [Int8Array, Int16Array, Int32Array, Uint8Array, Uint16Array, Uint32Array].some(A => x instanceof A)
}
}
new Float64Array(10) instanceof IntegerArray //false
new Int32Array(10) instanceof IntegerArray //true
これなら柔軟に対応できる。ちなみにClassも継承を活用できていい
class IntegerArray extends TypedArray {
static [Symbol.hasInstance](x) {
return super(x) && x[Symbol.toStringTag].contains('nt')
}
}
- 526 ：デフォルトの名無しさん：2014/01/18(土) 17:02:05.76
- なるほど型判定にinstanceofを使えばいいんだな
しかし[Symbol.hasInstance](x)って見慣れない構文だな…
x[Symbol.toStringTag]も
どこ見ればいいか教えてもらえると助かる
- 527 ：デフォルトの名無しさん：2014/01/18(土) 21:26:39.22
- 前者はMethodDefinition
ObjectLiteral
↓{ PropertyDefinitionList }
↓{ PropertyDefinition }
↓{ MethodDefinition }
ClassExpression
↓class BindingIdentifier ClassTail
↓class Identifier extends AssignmentExpression { ClassBody }
ClassBody
↓ClassElementList
↓ClassElement
↓static MethodDefinition
MethodDefinition
↓PropertyName ( StrictFormalParameters ) { FunctionBody }
↓ComputedPropertyName ( FormalParameters ) { FunctionBody }
↓[ AssignmentExpression ] ( ) { FunctionBody }
後者は「known symbol」でドラフトを検索してみるといい
- 528 ：デフォルトの名無しさん：2014/01/21(火) 07:00:19.03
- try { (ﾉ°□°）ノノ ┻━┻ } catch() { ┬─┬ ノ( ゜-゜ノ) }
- 529 ：デフォルトの名無しさん：2014/01/21(火) 14:32:33.68
- ドラフトr22来たね
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22
１つ挙げるとしたら
System.globalでグローバルオブジェクトが取れるようになったのは嬉しいね
- 530 ：デフォルトの名無しさん：2014/01/25(土) 07:24:58.43
- 例のwith proxyでvalue objectと演算子オーバーロードがエミュレートできるな
概念を書くと例えば
v = vo1 + vo2 * vo3
のとき
get vo1 → get vo2 → get vo3 → set v vo1 + vo2 * vo3
のリクエストが受け取れる
ここでvalue objectがgetされたときは適当な数値で返しながら覚えておく
例えばそれぞれ2.1、3.2、4.3とか
するとこの場合「set v 15.86」リクエストがあった時、実際の処理は2.1+3.2*4.3だったであろうことが逆算でわかる
つまりvにvo1+vo2*vo3の意味するとこの結果を代わりに設定して、その後のget vで返すことができる
これでマズイこともあるが、かなりのパターンのオーバーロードができそう
もう一つ思いついたのは、クロージャなしで任意の変数を関数に紐付けできる
WeakMapにcalleeとオブジェクトを紐付ければそれっぽくできるか
with(scope(arguments)){
$static, hoge, fuga, puyo, $
}
みたいな素敵な宣言文も定義できる
- 531 ：デフォルトの名無しさん：2014/01/31(金) 06:23:51.84
- 今やってるTC39ミーティングはES7がいよいよ始まったって感じで興味深いね。
Structured Clone、Typed objects、Value object、Parallel、Object.observe、Do expression、Async/await
その中のTyped objectsのスライドも面白い。
https://docs.google.com/presentation/d/1HGoxjX74Q9i8I1ok-hkmxzWlM7CDQwxT0sUS5PJDxdg/
tobj.bufferで仮想的なメモリダンプができて、それを一旦保存して同型のコンストラクタに食わせることで復元したりも出来そうだね。
個人的お気に入りなのは『do式』
見た目はdo-while文のwhile以降がない形で、最後の評価値を返すブロック文のような式。
見送られたlet文のより良い代わりになったり、複数行アロー関数でのreturnの省略など、かなり素敵に役に立ちそう。
var v; let (r = rand()) { v = b*n|0 }
↓
var v = do {let r = rand(); b*c|0 }
func = () => { ......; return hoge }
↓
func = () => do{ ......; hoge }
ES6はいよいよ詰める作業に入ったね。
おそらくもう一回、３月末のミーティングを終えてから、４月くらいに最終草案が出来るんじゃないかな。
- 532 ：デフォルトの名無しさん：2014/01/31(金) 19:19:33.18
- Value Objectsのスライド面白いね。
http://www.slideshare.net/BrendanEich/value-objects2
興味深いのは数値にサフィックスを付けて独自の型を定義できるようになったことだろうか。
1KB + 1MB // 1025KB とかできるわけだ。
更に演算子での暗黙の型変換を簡単に調整できるかもしれない。
awaitの情報も面白い。
https://github.com/lukehoban/ecmascript-asyncawait
Promiseが活躍してるね。
- 533 ：デフォルトの名無しさん：2014/02/01(土) 01:35:24.81
- 単体doはPerlを思い出すな
- 534 ：デフォルトの名無しさん：2014/02/03(月) 21:58:06.74
- 最近JSのマクロでsweet.jsが流行ってるけど、ES8のマクロはこれがベースになりそうな予感
- 535 ：デフォルトの名無しさん：2014/02/03(月) 23:27:10.33
- ES8って…鬼が笑いそうだな(節分だけに)
- 536 ：デフォルトの名無しさん：2014/02/04(火) 00:01:33.82
- ラムダっちゃ
- 537 ：デフォルトの名無しさん：2014/02/04(火) 06:06:37.19
- >>535
ES6の勧告は今年末
ES7の勧告はその２年後（つまり今から約３年後）を予定してるとなると
ES8の勧告は2020年になるまでには……って感じだろうな
でもこれまでの流れを見ると、ES7が大方固まったころ、つまり今から２年後にはES8の仕様もミーティングで話されていくし、
その１年前、つまりES6が勧告される頃には、メーリングリストで議論されてstrawmanに候補が挙げられだすのが定跡
つまり、ES8を考えだすのは来年の話でもないと思う
そもそもSweet.jsはMozilla製だし、macro文とかdef文とかESに取り込まれることを狙っているのかもしれない
あともう一つ挙げるなら、かつてES8だと思われてた機能も今のところマクロ以外はみんなES7になったし、
ES7だと思われてたPromiseが急遽ES6に入った例もあるから
マクロもSweet.jsみたいなのがPromiseライブラリ並みの存在になればもしかしたら……ってのはある
- 538 ：デフォルトの名無しさん：2014/02/04(火) 06:18:04.99
- 春にはV8でもアロー関数が使えるようになりそうだよ！！
やったねたえちゃん！
https://code.google.com/p/v8/issues/detail?id=2700
- 539 ：デフォルトの名無しさん：2014/02/05(水) 06:02:48.34
- 今までWorker間のデータのやり取りはコピーか移譲しかできない件でいろいろ議論があったが、
V8/ChromeでArrayBufferの共有をできるようにするみたい。
オマケで排他処理を利用したスレッド制御ができるようになる。
https://chromiumcodereview.appspot.com/148283013/
https://chromiumcodereview.appspot.com/149053009/
https://chromiumcodereview.appspot.com/149053009/diff/1/src/arraybuffer.js
- 540 ：デフォルトの名無しさん：2014/02/06(木) 10:10:23.63
- 先日の会議でPromiseに関してchainを廃止してcastをresolveに統合することになったんだけど、凄い揉めてる
http://esdiscuss.org/topic/promise-cast-and-promise-resolve
似たのがあるのはややこしくて無駄
chainとthen、resolveとcastでそれぞれ前者がベーシックで、後者が実用的という感じだろうか
で、残すとなると実用的な方になるのはもっともだが、
ベーシックな方を捨てると、関数型スタイルとしての魅力を大きく損ない、ただのサポートAPIに成り下がってしまう
皆Promiseに対して考えてる重みが全然違う
高レベルなフレームワーク追加と思うかパラダイム導入と思うかでぜんぜん違う
宗教的な部分も関わってくる
もっと根本的な設計から文句がある人もいる（決まるのが急すぎた！）
今でも案が出るし、PromiseじゃなかったらとっくにES7に持ち越しになってると思う
今後どうなるか注目
- 541 ：デフォルトの名無しさん：2014/02/06(木) 18:21:27.41
- こんな感じ？
〜ML〜
chain(flatMap)が要る要らないというようなことが半年前から度々話されてきた
〜そして先週の会議〜
「要らないよね〜」
「無くすのでいいと思う」
（ほぼ満場一致ですぐ決まる）
〜ML〜
「解決したよ〜^^ chainとresolveは無くすね」
「これはひどい＞＜」
「話が違うじゃねえかざけんな！」
「オンラインでの積み重ねを大事にしろよ」
・Googleの人
「あー、会議に出れなくて言えなかったのマズったな
ま、周りではchain推しだしV8では無くさないことにしたから^^;
（そもそもthenがクソだからchain実装したんだし！）」
「でも会議にでなかった人が決議を取り消せたら進展しないよね…」
『『『会議の意義って…………』』』
そして遂に出てしまった危険ワード「disasters like ES4」に皆が内心震え上がりましたとさ
爆死
- 542 ：デフォルトの名無しさん：2014/02/16(日) 06:09:25.38
- http://wiki.ecmascript.org/doku.php?id=strawman:relationships
これでprivateメンバを実現する仕組みは分かったんだけど
イマイチ他の有り難みが分からない
もしかして
f.set(b, v1)
f.set(b, v2)
f.set(b, v3)
x = f.get(b)
に比べて
b@f = v1
b@f = v2
b@f = v3
x = b@f
の形だと３変数を関連付けする意味も持ってるから
x = v3
とコードを最適化できるってこと？
それと、もしこうなったらなんかヤバイね
http://esdiscuss.org/topic/merging-bind-syntax-with-relationships
- 543 ：デフォルトの名無しさん：2014/02/19(水) 19:12:47.88
- CやC++もそうだけど、最新仕様にジワジワ対応してくのがいやだな
ベンダー中立なのも善し悪しだ
- 544 ：デフォルトの名無しさん：2014/02/20(木) 00:50:48.29
- es6のletも関数の先頭に巻き上がるの？
- 545 ：デフォルトの名無しさん：2014/02/20(木) 06:13:15.91
- let,constはブロックスコープで巻き上がらないよ
因みに関数宣言はブロックスコープで巻き上がる事になった
スコープに関してはこの２点を押さえとけばいい
- 546 ：デフォルトの名無しさん：2014/02/20(木) 10:54:52.79
- どうもどうも。
つうことはlet,constだけを使ってる限りは、C++と同じように使う直前で宣言する
っていうルールでいいわけだ
- 547 ：デフォルトの名無しさん：2014/02/20(木) 18:47:18.88
- 逆じゃね？
巻き上がるvarは先頭で宣言する意味が無いけど、
letはブロック文の先頭にやった方がいいと思う。
var a
if(f) { a = 1 }
else { a = 2 }
は
if(f) { var a = 1 }
else { var a = 2 }
とできるし、そのほうが分かりやすい。
letだとこれができない。
で、分岐の前で宣言するようなことをちまちますると分かりにくいから、
いっそそのブロックの先頭でまとめて宣言した方が分かりやすい。
constは定数なので当然先頭のほうが分かりやすい。
- 548 ：デフォルトの名無しさん：2014/02/20(木) 20:11:08.24
- 'use strict';
var a = 1;
function hoge() {
// ↓グローバル変数にアクセスするつもり
console.log(a); // => undefined (巻き上げの為)
var a = 2;
// aを使う処理
};
--------
let a = 1;
function hoge() {
// ↓グローバル変数にアクセスするつもり
console.log(a); // => 1 (のはず未確認)
let a = 2;
// aを使う処理
};
と直感的になるから使う直前で宣言するで問題無いよ
- 549 ：デフォルトの名無しさん：2014/02/21(金) 06:02:18.19
- >>548 あくまで変数はスコープに属する
つまり正確には変数の存在は巻き上がるというかスコープに浸透する
但し宣言箇所までに使おうとするとエラーになる
だからletさえあれば必ずしも良く書けるというわけでもない
特にfor文ではletは一見凄くいい
最近Cと同様に毎ループスコープコンテキストを生成するようになった
これでfor文中でのクロージャ生成がグッとよくなる
ただしその影響でパフォーマンスに影響があるかもしれない
理論的にはループ中にスコープコンテキストを保持するものがない場合
コンテキストを生成しなくて済むが、実際最適化が進むのは時間かかる
いずれにせよ、letはキチッとしたイメージで使っていくべきだと思う
>>547のような場合は、もし使う直前で宣言するのなら
それはそれ以前に変数を使っていた場合にエラーにしたいからという理由に自ずとなる
だがもし>>548のように見えて、キチッとしてないと思うのならブロック文の最初で宣言すべき
ただ大半のケースであろう、そのスコープだけで下位のスコープでは使わない場合
一気に宣言と代入をした方がコンパクトでいいとは思う
場合によっては先頭にする、また場合によってはvarも使うというように
個人的ポリシーのもと綺麗に使い分けるか、思い切ってvarを捨てて
letのその場宣言に統一するか、どちらがいいかは分からない
- 550 ：デフォルトの名無しさん：2014/02/21(金) 10:47:15.29
- 変数の定義は出来る限り後にするってのはEffectiveC++にも書いてある事だし
let,constを使ってる限りはその習慣のままでよくなったって事でいいよ
- 551 ：デフォルトの名無しさん：2014/02/25(火) 17:51:36.53
- ES6ってEffectiveC++まで読まないと使いこなせないのか…
- 552 ：デフォルトの名無しさん：2014/02/25(火) 23:03:38.54
- >>551
んなわけない
C++の人がJS のヘンテコな仕様を気にしなくてよくなっただけだ
- 553 ：デフォルトの名無しさん：2014/03/20(木) 20:37:22.08 ID:OnvdowAM
- ES7+に関するニュースがたまってきた
まずObject.observeがChrome M35でデフォルト有効になるね
つまり日本時間の4/1からES7の時代なわけだ、素晴らしい
それからES6に摂りこぼしたようなメソッドが入ってくる
http://esdiscuss.org/topic/object-entries-object-values
まあこういうのは仮にES7になっても、すぐ実装される可能性が高いか
あと興味深かったのはASTならぬCSTについて
http://esdiscuss.org/topic/concrete-syntax-tree
これが標準APIとして入ると、最近2chでもよく耳にするJSのコード分析ツールが発達するだろうね
- 554 ：デフォルトの名無しさん：2014/04/06(日) 10:34:50.10 ID:BAtZ8TGv
- Microsoft、プログラミング言語“TypeScript”を正式リリース
http://www.forest.impress.co.jp/docs/news/20140403_642703.html
- 555 ：デフォルトの名無しさん：2014/04/26(土) 00:52:27.92 ID:FOzpDrfL
- しかし、letが使えない事が最もイラつく要因だな
これだけは間違いなく設計ミスと言わざるを得ない
はやいとこletが当たり前のように使えるようになってほしいよ
- 556 ：デフォルトの名無しさん：2014/04/26(土) 04:17:27.66 ID:m4NkAp8y
- Let it be.
- 557 ：デフォルトの名無しさん：2014/04/26(土) 06:30:34.96 ID:IOWbf8hT
- なんでそんなもんが要るのか理解に苦しむ
- 558 ：デフォルトの名無しさん：2014/04/26(土) 07:34:51.39 ID:/1bv/NFj
- letって糖衣構文だよね？
- 559 ：デフォルトの名無しさん：2014/04/26(土) 09:05:12.45 ID:N/wOneBP
- letをラムダ式で書くのは一般に可読性がすごく悪いので、letがラムダ式の糖衣構文であることは
間違いないけど、良い糖衣構文の典型例と言っていい。
おまけにJSのラムダ式は function とか無駄にキーワードも長いし（funcで十分ですお）。
- 560 ：デフォルトの名無しさん：2014/04/26(土) 09:28:02.77 ID:dytsHLSj
- そもそもムダ式の使いどころがわからないｗ
- 561 ：デフォルトの名無しさん：2014/04/26(土) 10:45:40.07 ID:/1bv/NFj
- (function って書きかたするだけで即時無名関数だってわかるし、可読性悪いと思わないな。
とはいえletは便利だと思う。
- 562 ：デフォルトの名無しさん：2014/04/27(日) 10:16:14.38 ID:J+hFW2BD
- 架空の構文を使うが、
let (a = a に与える値, b = b に与える値) { a とか b とかを使ったプログラム片 };
↑コレが、こうなる↓
(function (a, b) { a とか b とかを使ったプログラム片 })(a に与える値, b に与える値);
可読性は大幅に違うと思うが？
- 563 ：デフォルトの名無しさん：2014/04/27(日) 12:50:33.35 ID:dzdj67m/
- var使えばいいじゃん
- 564 ：デフォルトの名無しさん：2014/04/27(日) 16:49:18.92 ID:/n7QikUK
- varか
- 565 ：デフォルトの名無しさん：2014/04/27(日) 16:58:01.12 ID:ZSKa5kXO
- バーカと言ってんのか。
- 566 ：デフォルトの名無しさん：2014/04/28(月) 07:32:48.30 ID:pTdZCSXw
- perlみたいにmyにすればvarより一文字タイプする手間が減って
人類全体ではおそらくのべ何百万時間と何百テラバイト節約できたのに。
- 567 ：デフォルトの名無しさん：2014/04/28(月) 10:37:13.73 ID:nTejnWG/
- そこでさらに1文字減らそうと考えないお前はとことん子供だな
- 568 ：デフォルトの名無しさん：2014/04/28(月) 12:21:34.72 ID:6N4YFPM8
- >>556
今なら let it go だな
- 569 ：デフォルトの名無しさん：2014/04/29(火) 01:06:54.91 ID:AbmpH0cg
- >>567
phpの$はすばらしいな！え、ちがう？
- 570 ：デフォルトの名無しさん：2014/04/29(火) 20:33:54.13 ID:pZyrXbny
- class構文書く時@@createとconstructorの役割の割り振りが難しそうだな
Arrayとか標準クラスを参考にすると@@create()ではそのクラスのインスタンスたり得る未初期化のオブジェクトを構築する
つまり例えばArrayならlengthや自然数がハックされた（Proxy）オブジェクトを作り、prototypeの継承もここでする
この時点で、obj.isClass()はtrueになるべきだが、まだオブジェクトが使える状態であってはいけない
その次にconstructor()で、this.isClass()がtrueならば実際の初期化を行い、使える状態にする
this.isClassがfalseまたは、初期化済みのインスタンスが渡された場合はエラーにする
逆にconstructorでオブジェクトをそのクラスのインスタンスたらしめる処理を行ってはいけない
例えば、内部的に使用するプロパティを新しく作成してはいけない
内部プロパティは@@create()でundefinedの値を入れて作っておき、constructor()ではそこに入れるだけにする
これを常に守っているクラス間では、多重継承や多重継承元オブジェクトの作成など柔軟性の高さを確保しつつ、安全なクラスシステムが定義できる
一方自由が好きな人でも、@@createを使いこなすことで自分好みのクラスシステムを再定義できる
例えば〜.prototype.〜は長いから〜.$.〜にしようとかも超容易にできる
- 571 ：デフォルトの名無しさん：2014/04/29(火) 21:23:55.12 ID:/EtEvdEl
- JavaのJavaScriptが更新されたね
- 572 ：デフォルトの名無しさん：2014/05/10(土) 00:26:41.76 ID:IHaPgo2n
- ES6のイテレータってJava8のStreamAPIみたいなメソッド無いの?
- 573 ：デフォルトの名無しさん：2014/05/29(木) 22:34:29.48 ID:fV0QO8N6
- マイクロソフト、IEの新機能紹介サイト「status.modern.ie」を正式版に
http://www.atmarkit.co.jp/ait/articles/1405/29/news127.html
- 574 ：デフォルトの名無しさん：2014/06/29(日) 11:40:45.08 ID:TYw9vhPY
- The ECMAScript 6 schedule changes
http://www.2ality.com/2014/06/es6-schedule.html
ECMAScript 6 will be finished (with the exception of fixing last bugs) by the end of 2014.
The publication process starts in March 2015 (and is finished in June 2015).
- 575 ：デフォルトの名無しさん：2014/07/01(火) 21:08:09.65 ID:Js6RRavd
- >>571
Rhinoのことかと思ったが2年前から止まってるように見える
ナスポンか？と思ったが
取り立てて新しく何かが変わったとも思えない
http://blogs.oracle.com/nashorn_ja/
何の話？
- 576 ：デフォルトの名無しさん：2014/07/03(木) 00:07:58.33 ID:vgh2JKeZ
- JDKに標準添付されているJavaScriptエンジンがJDK7まではRhinoだったのがJDK8からはNashornになったという話じゃないかい
- 577 ：デフォルトの名無しさん：2014/07/05(土) 00:02:39.57 ID:RY+GPlGn
- なるほど
Java「標準・付属」のJavaScriptが更新, ってことね
- 578 ：デフォルトの名無しさん：2014/07/05(土) 13:19:10.45 ID:ZUhQa0cg
- letはwith使えば良いじゃん。
with( {i:0} )
{
}
- 579 ：デフォルトの名無しさん：2014/07/05(土) 13:35:18.12 ID:ZUhQa0cg
- ESはclassよりprototype方面を強化してほしいなぁ。
Echo = {};
Echo.print = function()
{
println( this.message() );
}
Hello = Object.create( Echo );
Hello.message = function()
{
return "Hello";
}
Hello.print();
Regexとか標準の型もこれと同じ方法で運用できると助かる。
- 580 ：デフォルトの名無しさん：2014/07/12(土) 02:21:05.50 ID:+Nt4iEa/
- これから262 vs 408の図になるのか？
- 581 ：デフォルトの名無しさん：2014/07/12(土) 04:09:33.46 ID:CXwmpbMP
- 408ってなにかと思ったらDartか
あれ使ってる人ホントにいるの？
- 582 ：デフォルトの名無しさん：2014/07/12(土) 13:42:14.74 ID:RL1PcgPd
- IEの全盛期でも誰もVBScript使わなかったのに
当時のIEよりシェア低いChrome限定の言語とかww
- 583 ：デフォルトの名無しさん：2014/07/12(土) 15:13:49.40 ID:uBkJb0ew
- Dartω
- 584 ：デフォルトの名無しさん：2014/07/17(木) 10:06:07.97 ID:7tNbJpr1
- >>170は予言者
- 585 ：デフォルトの名無しさん：2014/07/27(日) 12:13:05.86 ID:m/wrXxPd
- arrow構文クソ過ぎワロタ
JSLintで使用禁止にされる未来が見える
- 586 ：デフォルトの名無しさん：2014/07/27(日) 12:32:11.50 ID:yFRKgWmm
- そんなこと言ってたらLISP以外使えなくなるぞ
どこらへんがクソなのか言ってみ
- 587 ：デフォルトの名無しさん：2014/07/27(日) 22:59:24.24 ID:xFZZEEcS
- >>585じゃないけどthisArgを固定されるのひどいと思う。
definePropertiesで省略できないじゃん。
- 588 ：デフォルトの名無しさん：2014/07/27(日) 23:43:52.05 ID:aHU39MPO
- それはメソッドの省略記法使えばいいんじゃ
Object.defineProperties(obj, {
abc: {
get() { /* ~~~ */ },
set(a) { /* ~~~ */ }
},
def: {
value() { /* ~~~ */ }
}
});
- 589 ：デフォルトの名無しさん：2014/07/28(月) 08:50:19.14 ID:Z2TAycCm
- 基本的に無名関数定義にをfunction使う必要がなくなったという認識。
イベントハンドラとかで、elementをthisにしたいときくらいかな
- 590 ：デフォルトの名無しさん：2014/07/28(月) 10:54:21.25 ID:7aaFLr4N
- Firefox のアドオンですでに結構使ってるけど、
主なユースケースとしては >>589 のいうように
Array#forEach とか Promise, EventListener などの無名関数だから
this が束縛されることに対する不便さは特に感じてないな
- 591 ：デフォルトの名無しさん：2014/07/28(月) 11:02:29.21 ID:/uFLkIvt
- arrowになって普通のスクリプト言語と同じになったのに、糞という奴は
相当今までのJavaScriptに毒されてんだろうな
そろそろ20年にもなる訳だから無理もないが
- 592 ：デフォルトの名無しさん：2014/07/28(月) 16:18:42.27 ID:CzzJnkp5
- 何故、無名関数定義にfunctionを使いたくないのかが分からない。
こうやって迷走させてDartとかに移行させるつもりなんだろうと思うわ。
- 593 ：デフォルトの名無しさん：2014/07/28(月) 18:48:36.54 ID:AsP8OCCj
- ES6以前からMozillaの独自拡張でfunctionの{}省略ってのができたのだから、
関数自体を短く書きたいという要求は多かったのでは？
コールバックを多用するライブラリの作り上の特性も関係してると思う
- 594 ：デフォルトの名無しさん：2014/07/28(月) 22:40:27.98 ID:4c7kN4U6
- funcぐらいなら毎回書いてもいいけどfunctionだと長すぎるかなー
てかJavaのラムダ式もこんな構文だし、まあ流行りってことで
- 595 ：デフォルトの名無しさん：2014/07/28(月) 22:43:19.97 ID:vVN/YTut
- 正直、短縮した "func" をキーワードにするだけで済む話だと思うのだが、
なんでこんなすったもんだするのか。
- 596 ：デフォルトの名無しさん：2014/07/28(月) 23:23:23.43 ID:3v5nU99l
- 何がすったもんだなのか全くわからん
C#勉強した方がいいぞ
arrowはほぼ一緒だし恥ずかしい事を言わずに済むよ
- 597 ：デフォルトの名無しさん：2014/07/28(月) 23:49:08.00 ID:oo2p7jTV
- もうLispで良いじゃんとしか思えん >>省略記法とか糖衣構文にまつわるｺﾞﾀｺﾞﾀ
- 598 ：デフォルトの名無しさん：2014/07/29(火) 01:28:07.02 ID:s+4NszZe
- >>595
キーワード追加は既存コードとの衝突があるし、
funcとか山ほど使われてるから大変なんだろう。
C++のautoとかは新キーワードかとおもいきやCの頃から存在してたが、
全く使われて居ない無意味なキーワードの再利用だから衝突しなかった。
- 599 ：デフォルトの名無しさん：2014/07/29(火) 08:12:11.87 ID:NiL3O2Wx
- ファンクチョン
- 600 ：デフォルトの名無しさん：2014/07/29(火) 10:24:48.27 ID:M1sSUXRJ
- > C#勉強した方がいいぞ
> arrowはほぼ一緒だし恥ずかしい事を言わずに済むよ
は？
- 601 ：デフォルトの名無しさん：2014/07/29(火) 23:01:25.64 ID:qMXADwlE
- ふ？
- 602 ：デフォルトの名無しさん：2014/07/31(木) 00:16:35.92 ID:kd/b1mjX
- ほ？
- 603 ：デフォルトの名無しさん：2014/07/31(木) 00:33:13.13 ID:RAmyBjAf
- ふ？
- 604 ：デフォルトの名無しさん：2014/07/31(木) 00:40:15.05 ID:ZI3BLt96
- >>603
そこは、「サッポロ一番カップスター！！！♪」だろう
- 605 ：デフォルトの名無しさん：2014/07/31(木) 02:17:14.31 ID:8j73UATf
- イベントハンドラとかでthisが変動するのって重要じゃないか。es6なんだからmoduleもthis変わるだろ？
そのとき実装が省略してarrow function使ったら仕様に出ないから分からずにthis固定されることになるじゃん。
その関数を使ったときcall/bindが期待通りに動かなくてソース読んで初めて判明することなるのは問題じゃない？
そもそも>>592の言うとおりes6が迷走し過ぎだと思う。
>>591
クロージャを()=>{}と書くのはsmalltalk系の流れだから現在は全くメジャーじゃない。変種のRubyのblockのほうが知られてるくらいじゃん。
javaなんて元はStrongTalkだから先祖返りじゃん。大体expression closuresはその20年くらい前からあるんだよ。
関数省略したいってのはその頃からある話でMSがjs2.0ゴネたから実装がjs1.8まで遅れたんじゃん。restとspreadだって同じでNSはずっとArgumentsオブジェクト止めたかったんだし。
>>592
DartかTypeScriptか忘れたけどthis固定する方法としない方法両方用意してるからそっちの方が優れてるよ。
- 606 ：デフォルトの名無しさん：2014/07/31(木) 13:35:25.30 ID:fRARZe7S
- 他の言語に慣れた人が「thisがころころ変わるのはキモイ」とかってごねたから
arrowのthisは今の仕様になったんじゃないの? 知らんけど
- 607 ：デフォルトの名無しさん：2014/07/31(木) 15:07:00.69 ID:/YLgyhx6
- NYscene
- 608 ：デフォルトの名無しさん：2014/07/31(木) 20:33:42.33 ID:d+uDxDT2
- >>605
> クロージャを()=>{}と書くのはsmalltalk系の流れだから現在は全くメジャーじゃない。
C#と一緒だからそれで十分だし、メジャーとかマイナーとか関係無い
- 609 ：デフォルトの名無しさん：2014/08/04(月) 23:13:41.46 ID:ht676QO2
- C#C#C#…馬鹿みたい
- 610 ：デフォルトの名無しさん：2014/08/05(火) 21:41:16.61 ID:pnN0YhcC
- 世界一実用性のある言語だから仕方ないね
- 611 ：デフォルトの名無しさん：2014/09/10(水) 10:38:50.98 ID:DN733PzP
- JavaScriptでは関数もオブジェクトだから Function instanceof Object がtrue
でもObjectは関数だから Object instanceof Function もtrue
何このループ
- 612 ：デフォルトの名無しさん：2014/09/10(水) 12:05:50.10 ID:oRU1JGkH
- >>611
型とコンストラクタをごっちゃにしてどうすんだ。
> Function instanceof Object → true
> Object instanceof Function → true
> new Function instanceof Object → true
> new Object instanceof Function → false
で、
> (function(Type){return Type instanceof Type}(function(){})) → false
> (function(Type){return new Type instanceof Type}(function(){})) → true
- 613 ：デフォルトの名無しさん：2014/09/10(水) 12:07:06.10 ID:oRU1JGkH
- ラストのわかりにくかったかもしれんので追加
> Array instanceof Array → false
> new Array instanceof Array → true
- 614 ：デフォルトの名無しさん：2014/09/10(水) 14:10:06.44 ID:5+X1+3dM
- typeof Function → function
typeof Object → function
要するに Object はコンストラクタ(関数)でもあり、全てのオブジェクトの親でもあるから
Function instanceof Object → 全てのオブジェクトは Object の派生であるから true
Object instanceof Function → Object は関数でもあるから true
だな
- 615 ：デフォルトの名無しさん：2014/09/11(木) 05:50:12.08 ID:p9H2bXgo
- > Object は関数でもあるから
「Object はObjectという型のコンストラクタ(関数)だから」と言った方が誤解を招かなくて済むと思うのだけど。
- 616 ：デフォルトの名無しさん：2014/09/11(木) 07:38:07.18 ID:BpRRpzGv
- 関数が Object
- 617 ：デフォルトの名無しさん：2014/09/16(火) 00:45:05.57 ID:/hQMl/mi
- 普通 Object は class なはずだけど JavaScript は関数からオブジェクトを作成するってのが
ヘンテコなところでもある
ES6だと class の定義が出来るけど、それを typeof したら何になるんだろうか？
やっぱり function か
- 618 ：デフォルトの名無しさん：2014/09/16(火) 05:56:23.72 ID:YhDmcrUx
- ES6のclassはただの糖衣構文だよ
- 619 ：デフォルトの名無しさん：2014/09/16(火) 08:23:52.39 ID:3lalmZe4
- >>617
classと型は別定義
仕様を読め
- 620 ：デフォルトの名無しさん：2014/09/16(火) 08:43:08.49 ID:/hQMl/mi
- >>619
だから function でしょ
- 621 ：デフォルトの名無しさん：2014/09/16(火) 08:51:39.75 ID:Qx/STD8f
- >>620
function という型はない
だから、仕様を読めといってる
- 622 ：デフォルトの名無しさん：2014/09/16(火) 12:50:37.70 ID:LFHVwXSY
- >>621
だから typeof した結果を聞いてんだよ日本語読めないのか？
- 623 ：デフォルトの名無しさん：2014/09/16(火) 13:59:20.29 ID:SSFY5Y3Q
- >>622
classを設定して型が変わったり、[[Call]] が付与されるわけないだろ
- 624 ：デフォルトの名無しさん：2014/09/16(火) 14:11:22.37 ID:SSFY5Y3Q
- >>617
ちゃんと、仕様を読んだ？
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation
- 625 ：デフォルトの名無しさん：2014/09/16(火) 14:54:14.12 ID:LFHVwXSY
- >>623
>>617で
> ES6だと class の定義が出来るけど、それを typeof したら何になるんだろうか？
> やっぱり function か
と聞いてんだぞ
何トンチキな事さっきから言ってんの？
お前が仕様以前に日本語読めてねーじゃん
- 626 ：デフォルトの名無しさん：2014/10/06(月) 21:47:17.31 ID:lTjGjScZ
- ECMAScript 6モジュールがCommandJS，AMDを超える
http://www.infoq.com/jp/news/2014/10/ecmascript6
- 627 ：デフォルトの名無しさん：2014/10/07(火) 11:54:16.18 ID:IxqWsXRE
- AMDとは一体…うごご
- 628 ：デフォルトの名無しさん：2014/10/26(日) 02:25:31.76 ID:cck0wHu4
- まともなこと言ってんのは>>612だけってどうなん。
rev 28-12.5.6.1-5.
Return a String according to Table 36.
Table 36 ― typeof Operator Results
Object (implements [[Call]]) "function"
だからclass defのtypeofの結果は"function"であってるよ。
js> class A{}
js> typeof A
"function"
js> Object.prototype.toString.call(A)
"[object Function]"
js> Symbol.toStringTag in A.prototype
false
>>626
moduleはいいけどこれ勘弁してほしいわ。
>Changed ordinary object creation to dispatch object allocation through [[CreateAction]] internal slot instead of @@create method.
>Converted all @@create methods into CreateAction abstract operations.
>Eliminated Symbol.create and @@create.
- 629 ：デフォルトの名無しさん：2014/10/26(日) 03:54:53.83 ID:4WZSXNcL
- >だからclass defのtypeofの結果は"function"であってるよ
んなこたみんなわかってる。
>>619が日本語読めないだけ。
- 630 ：デフォルトの名無しさん：2014/10/27(月) 12:10:16.79 ID:qnYU7yPZ
- >>628
> js> class A{}
> js> typeof A
> "function"
これってどんな環境で確認したの？
- 631 ：デフォルトの名無しさん：2014/10/27(月) 12:41:27.17 ID:2WnnLMYe
- 説明無しにオナニー披露してんだから
ふれちゃだめ
- 632 ：デフォルトの名無しさん：2014/10/28(火) 00:48:41.70 ID:l8UbZ1qe
- >>630
http://github.com/anba/es6draft
実装で確認しなくても14.5.14 Runtime Semantics: ClassDefinitionEvaluationのconstructorParentが%FunctionPrototype%なんだから分かるだろ。
- 633 ：デフォルトの名無しさん：2014/10/28(火) 11:13:32.92 ID:FzOeccCw
- >>632
これか
いやclassの型とかもはやどうでもよくて、単に実行環境を知りたかっただけ
こういうのをサクっと作っちゃうのはスゲーな
しかもガイジンにしちゃソースの可読性がハンパなくいいな…
- 634 ：デフォルトの名無しさん：2014/10/29(水) 00:29:46.52 ID:UnaJRfaO
- anbaってHN見て知らないなら開発者じゃないな。
- 635 ：デフォルトの名無しさん：2014/10/29(水) 11:22:25.04 ID:GiyQXeuL
- 開発者だが全然知らん
- 636 ：デフォルトの名無しさん：2014/10/29(水) 15:58:32.15 ID:UGMr0/mG
- でたー通気取り
- 637 ：デフォルトの名無しさん：2014/10/29(水) 19:18:31.93 ID:aEUBjZdG
- >>633
> しかもガイジンにしちゃソースの可読性がハンパなくいいな…
これは偏見
- 638 ：デフォルトの名無しさん：2014/10/29(水) 20:57:04.63 ID:GiyQXeuL
- >>637
いやもちろん単なる主観でしかないが、こないだもOpenSSLのソースは猿が書いてるとか
言われてたし、メジャーなオプソでも意外と可読性気にせずガリガリ書いちゃってるのは
あるにはある
- 639 ：デフォルトの名無しさん：2014/10/29(水) 21:17:27.14 ID:LJBpagLw
- 可読性どころか
ループできるところをループせずにコピペの塊だったりする
- 640 ：デフォルトの名無しさん：2014/10/29(水) 22:00:42.11 ID:gF0+F/K+
- >>638
jQuery作者とかCrockfordとかソースの可読性に気を使っているガイジンはたくさんいるんだが
Googleだってアメリカの会社だ
日本人のコードが特別優れているようには思えない
- 641 ：デフォルトの名無しさん：2014/10/30(木) 00:42:17.78 ID:GWxr5Wfx
- たしかに外人は文字列周りとかやたらhard-wiredなコーディングしてたりするけど
OpenSSLは古いし報告済みの脆弱性が放置されてるからあれを基準にしちゃダメだろ。
それこそ猿が書いたコードと人間が書いたコード一緒にするなよ。
- 642 ：デフォルトの名無しさん：2014/10/30(木) 02:02:24.47 ID:4GsvotLh
- >>641
猿が書いたって単なる比喩なのに、人間書いたコードと一緒するなとか意味不明
- 643 ：デフォルトの名無しさん：2014/10/30(木) 13:22:00.04 ID:NixeW727
- そもそも日本人は可読性に優れたコードを書くというソースはどこ？
- 644 ：デフォルトの名無しさん：2014/10/30(木) 14:19:18.20 ID:cKYS02DZ
- 最長不倒関数でググれ
- 645 ：デフォルトの名無しさん：2014/10/30(木) 19:07:37.96 ID:CaPdDXNn
- >>642
馬鹿だろお前
- 646 ：デフォルトの名無しさん：2014/10/30(木) 21:26:41.19 ID:X7YwtfwB
- >>645
顔真っ赤w
- 647 ：デフォルトの名無しさん：2014/10/31(金) 07:03:48.45 ID:PyU9LtcS
- >>643
クソみたいなコーディングルールでガチガチに縛るのを横行させた実績はある。
………………策定した奴らにとってはあれが可読性に優れたコードなんだよ！
- 648 ：デフォルトの名無しさん：2014/10/31(金) 17:48:27.50 ID:a4e/cHmb
- コーディングルールでガチガチに縛るのは海外も変わらんよ。
違うのは海外勢はガキの頃からcomputer geekでコード書いてるのが当たり前でそういう連中はちゃんとしたコード書けるってことだけだ。
- 649 ：デフォルトの名無しさん：2014/10/31(金) 21:30:43.56 ID:ztUoI9Xi
- 頭のおかしいルールがまかり通る、とかの実質で比較しなきゃ空論以前だな。
- 650 ：デフォルトの名無しさん：2014/10/31(金) 22:55:01.00 ID:ujQGPjLm
- ジャンガリアンの悪口早めろ
- 651 ：デフォルトの名無しさん：2014/10/31(金) 23:16:47.41 ID:ZqadJ9Dt
- スレ違いどころか板違いだな woo
- 652 ：デフォルトの名無しさん：2014/11/01(土) 15:34:42.75 ID:D3G7iSJM
- ハンガリアンは元々暗号めいてるC言語の型の表記方法に加えて、さらにややこしくnearとか
farが付くというマジキチなMS-DOSやWin16のC言語では意味がある。
あとシステムハンガリアンとアプリケーションハンガリアンはちゃんと区別しような。
- 653 ：デフォルトの名無しさん：2014/11/01(土) 15:37:55.94 ID:Wy2Pqs6J
- システムハンガリアンで役に立つのってポインタを表すpくらいじゃねぇの？
アプリケーションハンガリアンはwebアプリだと汚染の伝達が見て解るから凄く好きだが。
- 654 ：デフォルトの名無しさん：2014/11/01(土) 18:45:04.77 ID:sM88bUQL
- ミトコンドリア化
- 655 ：デフォルトの名無しさん：2014/11/03(月) 12:41:43.96 ID:G+HpWTk6
- V8にClass構文が実装された
http://js-next.hatenablog.com/entry/2014/11/01/034607
明日には使えなくなるES7トーク
http://azu.github.io/slide/es6talks/
- 656 ：デフォルトの名無しさん：2014/12/23(火) 19:57:35.63 ID:aN/aWLOo
- PromiseにNotifyのような継続したメッセージング機能がないのなんでだろ
jQueryから離れらんないじゃん
- 657 ：デフォルトの名無しさん：2014/12/23(火) 22:28:18.80 ID:7XMi2k1J
- それstreamで
- 658 ：デフォルトの名無しさん：2014/12/23(火) 22:45:20.05 ID:fSPsfgoT
- それECMAの仕様に入ってる？
- 659 ：デフォルトの名無しさん：2015/02/02(月) 17:49:21.74 ID:8JTprJa1
- 亀だがwhatwgで仕様策定中
とりまとめはpromiseと同じ人
https://streams.spec.whatwg.org
- 660 ：デフォルトの名無しさん：2015/02/11(水) 22:22:49.29 ID:uYJNlxq3
- WHATWG(笑)
ブラウザの事しか考えてないゴミじゃねーか
- 661 ：デフォルトの名無しさん：2015/02/13(金) 01:17:00.69 ID:Mf2kmdAI
- メッセージングとかそこらへんはhost側でやればいいじゃん。
アーキテクチャ毎に最適解が違うしシングルスレッドかマルチスレッドかでそのアーキテクチャも変わるでしょ。
asyncとかPromiseみたいなどうでもいいもんを仕様に入れようとする今の流れがおかしい。
>>660の言う通りブラウザのことしか考えてない。
- 662 ：デフォルトの名無しさん：2015/02/13(金) 01:38:32.09 ID:pVjZSa7s
- node全否定？
- 663 ：デフォルトの名無しさん：2015/02/13(金) 08:42:57.87 ID:OQXQ5SVC
- >>661
ほんそれ
- 664 ：デフォルトの名無しさん：2015/02/13(金) 14:14:34.12 ID:Vaa+aRRv
- jQueryから離れらんない人(>656)がブラウザ依存を嫌う理由がわからん
- 665 ：デフォルトの名無しさん：2015/02/13(金) 14:41:09.78 ID:FzPhDDc+
- その前になぜ同一人物だと思ったのか
- 666 ：デフォルトの名無しさん：2015/02/13(金) 16:00:33.10 ID:yMUA5bk4
- promiseもstreamもサーバサイド発なのになぜブラウザのことしか考えてないことになるのか？
- 667 ：デフォルトの名無しさん：2015/02/14(土) 22:58:03.71 ID:Vw0/10WS
- promiseはjQuery.Deferredじゃないか？
そもそもfutureとpromiseは並列プログラミング一般のデザインパターンだろ。
javaも標準でconcurrentフレームワークにfutureがある。
- 668 ：デフォルトの名無しさん：2015/02/15(日) 00:36:37.08 ID:Hyp4I7Sf
- ES6のPromiseは直接的にはサーバサイドJSの標準化をしていたCommonJSのPromise/A+仕様が元
- 669 ：デフォルトの名無しさん：2015/02/15(日) 00:42:21.54 ID:S4JnhDwu
- jQuery が元になった仕様は Selectors API ぐらいかな
- 670 ：デフォルトの名無しさん：2015/02/26(木) 21:43:09.84 ID:0l3fh5cz
- 継続したメッセージングはES7のObservableが担う。
https://docs.google.com/file/d/0B7zweKma2uL1bXJreWt0WmhZYzg/edit
https://esdiscuss.org/notes/2014-06/async%20generators.pdf
- 671 ：デフォルトの名無しさん：2015/03/15(日) 08:50:59.63 ID:FBF5ygu7
- ES7 の Async/Await を使ってみた
http://qiita.com/mohayonao/items/435665065d997a4cc50c
- 672 ：デフォルトの名無しさん：2015/03/15(日) 22:34:17.73 ID:pWk0O9jh
- ECMAScript没proposal追悼式
http://www.slideshare.net/KMC_JP/ecmascriptproposal
- 673 ：デフォルトの名無しさん：2015/03/26(木) 23:08:25.23 ID:s9zycqBk
- http://news.dartlang.org/2015/03/dart-for-entire-web.html
＞We have decided not to integrate the Dart VM into Chrome.
AtScriptも死んだし、Googleは何がやりたかったんだ…
- 674 ：デフォルトの名無しさん：2015/03/26(木) 23:45:15.66 ID:zVd7DNdf
- 数打ちゃ当たるっす
それでGoが当たったっす
- 675 ：デフォルトの名無しさん：2015/04/07(火) 08:58:18.88 ID:QCGCN9/k
- https://twitter.com/awbjs/status/580326814826020864
The final ES6 draft will be RC4 which I will finalize and forward to Ecma next week.
- 676 ：デフォルトの名無しさん：2015/04/21(火) 23:28:30.98 ID:8EI4QcJG
- https://twitter.com/awbjs/status/588811606236106755
Final Draft of the ECMAScript 2015 Language Specification (ES6) is now available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_draft
… Next step: Ecma GA approval vote
- 677 ：デフォルトの名無しさん：2015/06/18(木) 22:26:54.71 ID:7ssfjqax
- http://www.ecma-international.org/publications/standards/Ecma-262.htm
ES6の正式版
- 678 ：デフォルトの名無しさん：2015/06/19(金) 09:24:24.11 ID:2MeRaLuW
- おめ
- 679 ：デフォルトの名無しさん：2015/06/19(金) 13:03:26.38 ID:X+CwqWOz
- こ
- 680 ：デフォルトの名無しさん：2015/06/19(金) 21:28:45.56 ID:wXHfwCo1
- のやろう
- 681 ：デフォルトの名無しさん：2015/06/22(月) 21:27:52.28 ID:TnvACVCk
- ECMAScript 2015は承認された
http://www.infoq.com/jp/news/2015/06/ecmascript-2015-es6
WebAssembly: Webのためのユニバーサルバイナリとテキストフォーマット
http://www.infoq.com/jp/news/2015/06/webassembly-wasm
- 682 ：デフォルトの名無しさん：2015/06/23(火) 23:10:45.17 ID:B0jclyrh
- お次はES7/ES2016か
今度の目玉は何じゃろね
- 683 ：デフォルトの名無しさん：2015/06/23(火) 23:45:10.33 ID:+OgVklpL
- decorator
- 684 ：デフォルトの名無しさん：2015/06/23(火) 23:45:44.95 ID:+OgVklpL
- あとasync/awit
- 685 ：デフォルトの名無しさん：2015/07/22(水) 02:09:12.38 ID:wbhhK6Bo
- ここは人は居るんですかね？
- 686 ：デフォルトの名無しさん：2015/07/22(水) 02:57:00.54 ID:wbhhK6Bo
- まあいいや、勝手に始めてみます。
Web製作板の質問スレは知っていますが、どうも合わないので。
多層継承を積極的に試したことがある人は居ますか？
もし居ましたら、問題点等があれば教えてください。
一応、googleのコーディング規約だと止めろということになっています。
> 多層のプロトタイプヒエラルキー
> 好ましくありません.
> http://cou929.nu/data/google_javascript_style_guide/
こちらで試したところ、デバッグのときに見にくくなる位で、それ以外は特に問題はありません。
これを止めるのは特性を殺してしまうことになるので、
問題なければさらに積極的に進めていこうと思っています。
あらかじめハマりポイントをご存知の方がいれば、教えてください。
- 687 ：デフォルトの名無しさん：2015/07/22(水) 04:22:07.08 ID:BwnFAFFg
- >>686
そこに書いてあるだろ？
問題点はなにか？
> こうしたヒエラルキーは理解するのが難しくなります.
"理解するのが"難しくなる。だ。動かないとかそういう問題じゃない。
そして理解するのが難しくなるという問題を解決する方法も書いてあるだろ。
> よって同様のことを実現したい場合は, Closure Library の
> goog.inherits() や類似のライブラリ関数を使うべきです
goog.inherits() や類似のライブラリ関数を使えばいい
- 688 ：デフォルトの名無しさん：2015/07/22(水) 05:06:11.83 ID:E5CPZFPu
- 継承の代わりにオブジェクトコンポジションを使えがセオリー
- 689 ：デフォルトの名無しさん：2015/07/22(水) 21:17:35.87 ID:wbhhK6Bo
- >>687
以前ちら見した限りでは、goog.inherits()はクラス的構文で書けるだけで、
何の役にも立たないという結論だ。
継承深度は変わらないので、デバッグの手間も減らない。
むしろ、googleがなぜそんな中途半端な結論になっているのかが分からない。
そちらの理解もこちらと同じく、見にくくなるだけが問題だ、というのは了解した。ありがとう。
>>688
スーパークラスの差し替えの予定は無い。
また、内部状態を持たないオブジェクト(辞書のようなもの)によるインスタンスツリーだが、何か危険かな？
オブジェクトコンポジションも見やすくはならない。継承深度は変わらない。(継承ではなく使用だが)
もちろんフラットに展開してオブジェクトコンポジション的に書くことは出来る。(今がそれに近い)
逆に基本的にオブジェクトコンポジションで書き、それぞれのプロパティを検査し、動的に折りたたむことも出来る。
こっちの方がいいかな？
目的は、単にJavaScriptのNative継承が使えるものなのかどうかの味見だ。
最初から捨てるのではなく、まずは試す。駄目なら捨てる。
既に駄目だとわかっているのなら、無駄足になるから先に教えて欲しい。
- 690 ：デフォルトの名無しさん：2015/07/22(水) 21:52:32.62 ID:7tiwD+gv
- いくつから「多層」なのか定義しないと議論にならなくね？
- 691 ：デフォルトの名無しさん：2015/07/22(水) 22:44:07.30 ID:BwnFAFFg
- >>689
> 以前ちら見した限りでは、goog.inherits()はクラス的構文で書けるだけで、
> 何の役にも立たないという結論だ。
あんた、可読性の重要さをわかってないでしょ？
シンタックスシュガーも同じだけど、
使わなくてもできるのに、あえて用意しているのは、
それを使ったほうが可読性が高くなるからなんだよ。
意味はもう少し実務経験を積んだほうがいい。
- 692 ：デフォルトの名無しさん：2015/07/22(水) 22:45:25.39 ID:wbhhK6Bo
- >>690
逆に、そちらではどれくらいの継承深度で書いているの？
こちらが勝手に定義していいのなら、2-3階層が「フラット」で、それ以上が「多層」になる。
こちらは、デフォのprototypeは使っている。
コンストラクタも用意してはみたが、正直あまりnewするメリットを感じないので、多用はしていない。
コンストラクタの中でのnewは1箇所あるかないかで、大半は2-3階層だ。(new_obj-obj-Object.prototype)
ただ、似て非なるインスタンスが多い場合、共通部分を切り出して継承するとコード/フットプリントを削減できる。
だから試してみた。多分5-6階層になっている。
問題は各オブジェクトの該当プロパティがどこに書いてあるか分かりにくいことだが、
これは、クラスツリーが形成される一般のオブジェクト指向言語でも同じことだ。
JavaScriptはインスタンスツリーも作れるから、こちらで試しているのだが、
インスタンスツリーは禁止でクラスツリーはいくらでもいいですよというのは変だ。
(JavaScriptはその区別をしていないし、
クラス的な使い方であっても動的に変更が効いてしまうという危険性はあるとしても）
ただ見たところ、見にくさ以外の問題点は感じられない。だから聞いてみている。
- 693 ：デフォルトの名無しさん：2015/07/22(水) 23:02:34.90 ID:wbhhK6Bo
- >>691
それが君にとって見やすいのなら、そう書けばいい。
それがチームにとって見やすいのなら、コーディング規約で縛ればいい。
俺はgoog.inherits()なんて余計に読みにくくなるだけのゴミだと判定しただけ。
だから俺は使わない。
あれはJavaScriptにクラス構文を導入するためのシンタックスシュガーだというのなら、その通りだ。
しかし俺は、JavaScriptネイティブの書き方で特に問題を感じない。
- 694 ：デフォルトの名無しさん：2015/07/22(水) 23:49:48.86 ID:74SecBJW
- 質問主は自分がやってることをコードで説明した方がいんじゃまいか？
階層の数以前にObject.create()や類似の方法による(self的)プロトタイプ主義と
C++/Java的なクラス主義との軋轢が先に表面化して話がかみ合ってないように見える
ま、ECMAScript6でクラス構文入ったからもうそれしか使ってないけどな、俺は
- 695 ：デフォルトの名無しさん：2015/07/22(水) 23:58:52.35 ID:AzhZ/4jT
- >>692
5〜6階層は普通だな、得に深いとは思わん
- 696 ：デフォルトの名無しさん：2015/07/23(木) 00:14:07.21 ID:YZXLVsiv
- クラスとインスタンスメソッドを排除してモジュールと関数にするのがベストだけどね
クラスは状態がない最小単位か状態の取り回しがどうしても煩雑になるときだけ使う
- 697 ：デフォルトの名無しさん：2015/07/23(木) 00:27:39.66 ID:1EdglOAT
- 別にわざわざ禁止にしなくても多重継承なんて滅多にする機会ないだろう
何でもかんでもクラスがないとインスタンスが作れない言語じゃないんだからさ
- 698 ：デフォルトの名無しさん：2015/07/23(木) 00:31:22.60 ID:Ywbp50dT
- 誰も多重継承の話はしてない件
- 699 ：デフォルトの名無しさん：2015/07/23(木) 00:36:45.00 ID:UCOFR8WX
- >>694
基本的に __proto__ を使っている。
Object.create()も結果的にあまり使っていない。
そもそも new もいらない子だという話もある。
実際 function の return でオブジェクトを返せるので、無ければ無いでも組める。
試しに new も使ってみたが、見やすくなるわけではない。（見にくくなるわけでもないが）
ただ、__proto__が開放されていなかったときには必要だったとは思う。
しかし __proto__ があるのなら、無くてもいい仕様だ。
prototype がいるから中途半端になっているが、実体は __proto__ によるオブジェクトツリーであり、
それをどう見せるかで色々糖衣構文が導入されているわけだが、
__proto__ で問題ない場合、糖衣構文を使う必要が無い。
実体と同じ記述の方が分かりやすいと感じる。
ちなみに俺はプロトタイプでも問題ない。（クラスでもいい)
クラスじゃないと嫌だという人にはクラス構文が必要だろうし、使えばいいとは思う。
- 700 ：デフォルトの名無しさん：2015/07/23(木) 00:47:37.17 ID:Ywbp50dT
- __proto__ってes6に入ったんだっけ？
でもes6ならclass使うし、es6じゃないならie10以前はいいのかっていう
oopなライブラリって環境非依存のためでもあるから、その辺の制約の有無も前提に必要やね
- 701 ：デフォルトの名無しさん：2015/07/23(木) 00:48:15.61 ID:UCOFR8WX
- >>695
ありがとう。参考になる。
ただ俺は5-6階層くらいで追いかけるのが面倒になって来つつある。
- 702 ：デフォルトの名無しさん：2015/07/23(木) 01:02:04.28 ID:UCOFR8WX
- >>697
モジュールというのは、一応ググって見たけど、
var module = (function(){
var obj;
// 中身
return obj;
})();
ということでいいのかな？
1個でよければこれでいいけど、沢山要るのなら new 出来るようにしておかないと駄目な気が。
俺も1個のときは必ずこれだけど。
- 703 ：デフォルトの名無しさん：2015/07/23(木) 01:02:48.66 ID:UCOFR8WX
- すまん、>>702 は >>696 宛て。
- 704 ：デフォルトの名無しさん：2015/07/23(木) 01:06:16.23 ID:Ywbp50dT
- es6のモジュール(import/export)のことでしょ
ってことは質問主はes6じゃないのか
それで__proto__使うってことはnode前提？
あと>>696はoop vs fpになるからさらに発散するぞw
- 705 ：デフォルトの名無しさん：2015/07/23(木) 01:14:31.68 ID:Ywbp50dT
- あー、でもnodeだと>>702な書き方はいらんよな
でも必ずそうしてるってことはnodeでもないってことか
どういう環境が前提なんだ？
- 706 ：デフォルトの名無しさん：2015/07/23(木) 01:16:58.96 ID:UCOFR8WX
- >>700
俺の制約は、
・chromeとFF、共に最新版でデフォの設定(flagsとかの指定なし)で動くこと。
GreaseMonkeyだからIEは不要。
旧バージョンサポートは、今の俺には無理だから最初から捨てている。
多分ES5なのだと思うが、ES6が動くのならそれでもいい。とにかくブラウザで動けばいいだけ。
俺のはかなり緩い制約だ。
君たちが別の制約でやっていて、最適策が異なるのは当然だと思う。
なお、__proto__ がES6で禁止されるのなら、それはちょっと悲しい。
Object.create({__proto__: xxx})だと、余分に1階層入ってしまうので。
- 707 ：デフォルトの名無しさん：2015/07/23(木) 01:27:13.57 ID:Ywbp50dT
- 逆、__proto__はes6「から」入った
それ以前は実装依存(だからie10以前では使えない)
- 708 ：デフォルトの名無しさん：2015/07/23(木) 01:30:49.66 ID:YZXLVsiv
- そもそも具体的に何がしたくて継承させてんだよ
それこそ宛がなくて発散するわ
あとスレチじゃね
- 709 ：デフォルトの名無しさん：2015/07/23(木) 01:33:01.32 ID:UCOFR8WX
- >>704-705
俺はC出身だからプログラミングそのものは出来るが、
JavaScriptについてはヒヨコだし、
それ以前にOOPも真面目にやっていなかったのでリハビリ中だ。
だからCとOOPの中間のプロトタイプというのは、俺には割と居心地がいい。
書き方は見よう見まねでやっているだけ。
ポリシーをもってやっている訳ではないので、
俺の書き方自体は「ググッタらそれが出てきたことがある」位の意味しかない。
色々試しているところ。
- 710 ：デフォルトの名無しさん：2015/07/23(木) 01:44:46.71 ID:UCOFR8WX
- >>708
目的は689,692に部分的に書いているが、
インスタンスの共通部分をマメに切り出して継承すれば、コード/フットプリントを削減できるんじゃないか？
しかしなぜgoogleはこれを禁止しているのだ？
ということ。クラスではなく、インスタンスツリーの継承はOOP言語では出来ないので、試してみている。
1を読む限り、このスレはECMAであれば雑談含めて何でもありだと読んだが。
> ECMA-262規格として知られる言語（通称 ECMAScript）についての利用法や言語仕様、
> その他四方山話をするスレです。(>>1)
Web製作板はIDが出ないのが問題のような気もするから、試しにこちらに落としてみた。
- 711 ：デフォルトの名無しさん：2015/07/23(木) 01:53:11.38 ID:Ywbp50dT
- >>709
最近始めたのならbabelでes6 class使うのがいいと思うけどね
ググるときは"es6"も含めるといいよ
今更過去の情報を参考にしても大概時間の無駄だろう
cでもk&r時代(ansi以前)の書き方参考にしないっしょ？
- 712 ：デフォルトの名無しさん：2015/07/23(木) 03:19:49.77 ID:UCOFR8WX
- >>711
ありがとう。
babelというのは初めて聞いたので、ちょっとググって読んでみた。
古い書き方を学ぶ必要は無いが、そもそも俺が古いので、古い書き方でも不便を感じない。
だからこれが最大の問題かもしれない。
ただそれ以前に、何が古いのかもよく分かってないんだが。
とはいえ、新しい書き方は古い書き方の問題を解決したものであるから、積極的に試すべきだとは思う。
ES6の新機能は以下の左列の feature で全部なのかな？
http://kangax.github.io/compat-table/es6/
つついてみたら展開してサンプルコードらしきものも出てくるが、
残念ながら今の俺では何がうれしいのか分からない。MDN待ちだ。
（どういう不便さを解決できる書き方なのかわからない）
とにかくbabelが先行しているのは事実のようだが、
それ以前にES6のおいしさを俺が理解できないのが問題だ。この点は申し訳ない。
ちなみに、基本的に面倒でも書ける物は何とかなるので、糖衣構文にはあまり興味が無い。
本質的な拡張（それが無いとどうしようもないもの）ってどれだか分かる？
Proxyとか、ObjectのハッシュキーをObjectにできる（Map）はそれなので、Built-insにあるものが全部かな？
- 713 ：デフォルトの名無しさん：2015/07/23(木) 03:38:45.99 ID:KV3OkSY4
- Babelが対応してないのは処理系の対応が必要な本質の拡張だと思っていい
class構文はArrayなど組み込みクラスを拡張する唯一の方法なのでただのシンタックスシュガーではない
- 714 ：デフォルトの名無しさん：2015/07/23(木) 06:17:45.03 ID:i2pTrUSs
- JSって言語としてはプロトタイプベースでも、処理系はクラスベース前提に最適化してるから、
必要がない限りはちゃんとコンストラクタ書いて全部のインスタンスプロパティを設定すべき
詳しくはhidden classでググる
- 715 ：デフォルトの名無しさん：2015/07/23(木) 06:41:35.69 ID:YZXLVsiv
- >>710
その抽象的な目的は経験的に間違いだと判断されてるので
経験から理解できないなら決まりとして覚えるしかない
コーディング規約と同じで個人の嗜好や理解の有無なんて考慮されない
だからここで人に聞いて経験なく理解しようとしても無理
>>714
ついでにいうとインスタンスプロパティの変更を2,3回以内に留めるとキャッシュが効くんだっけか
- 716 ：デフォルトの名無しさん：2015/07/23(木) 06:56:39.36 ID:YZXLVsiv
- 違った、値でなく型の種類だった
でもこの型(hidden class)はオブジェクトリテラルで書いても
認識されるみたいだからクラスにする必要はないんじゃない？
- 717 ：デフォルトの名無しさん：2015/07/23(木) 21:33:34.18 ID:UCOFR8WX
- >>713
> Babelが対応してないのは処理系の対応が必要な本質の拡張だと思っていい
なるほどありがとう。これは賢い見分け方だ。(babelが完成しているという前提だが）
> class構文はArrayなど組み込みクラスを拡張する唯一の方法なのでただのシンタックスシュガーではない
いやただのシンタックスシュガーだという話だが。どこまでがその範囲かという話の気もするが。
http://js-next.hatenablog.com/entry/2014/11/01/034607
ただ、class構文の方が見やすいのは認める。
- 718 ：デフォルトの名無しさん：2015/07/23(木) 21:36:01.95 ID:UCOFR8WX
- >>714
> JSって言語としてはプロトタイプベースでも、処理系はクラスベース前提に最適化してるから、
この判断がそもそもおかしい。(hidden classについて君が勘違いしているだけかもしれんが。後述）
プロトタイプベースをクラスベースで処理して最適なわけがない。どうやってもオーバーヘッドが生じる。
（実装としては大して変わらないというのはさておき）
ただ、クラスベースで書かれた物についてはマッチするし、実際にこれも多いだろう。
つまり、問題はJavaScriptエンジニア自身がプロトタイプを使いこなせていない点にある。
使いこなすに値するかは別の問題だが。
クラスで出来なくてプロトタイプで出来るのはインスタンスツリーで、これは今試している。
後はやはり動的継承だが、これについては今のところやりたい局面が無い。
- 719 ：デフォルトの名無しさん：2015/07/23(木) 21:36:40.04 ID:UCOFR8WX
- >>714
V8についての記事を少し読んでみたが、hidden class はクラスベースの最適化を目指しているのではなく、
プロパティアクセスを高速化するためにオブジェクトを静的構造体にして決め打ちにするためだ。
このとき、どの構造体なのかを判別するために使っている。
クラスベースのJavaScriptのためではない。内部的に各オブジェクトを各クラスとして扱っているだけだ。
https://developers.google.com/v8/design
http://jxck.hatenablog.com/entry/20111110/1320883625
>>715-716
プロパティアクセスについてはMSDNに書いているとおり、最初に全部まとめて作って後で追加しなければ最適化がかかる。
V8でも同じような仕組みで高速化しているだけの話だ。
（ただ、本当に全面的に hidden class の実装にした場合、常に静的構造体アクセスになるので、
後からいくら追加/削除/型の変更をしてもアクセスそのものは遅くならない。
遅くなるのならそういう実装ではないということになる。
ただ、最適化についてはエンジンに依存するが、いちいちこれを言い出したら面倒なので通常は省かれている。
だからその話もV8では対策済みなのかもしれない。）
https://msdn.microsoft.com/ja-jp/library/windows/apps/hh781219.aspx
>>716
全面的に hidden class の実装なら、
オブジェクトリテラルで書いても、あるいは、どういう書き方をしても、 hidden class になる。
- 720 ：デフォルトの名無しさん：2015/07/23(木) 21:37:51.54 ID:UCOFR8WX
- >>715
指摘はその通りだ。
しかし、俺はもう既にgoogleを信用していない。だからgoogleが言っている事は鵜呑みにしない。
googleのエンジニアの質も相当に低い。
理由はあっちのスレにも書いたがGCの件だ。
JavaScriptにおける循環参照その他の「使い方によるメモリリーク」は全て対策されているようだ。
つまり、全てブラウザのバグだったということだ。
エンジニアの数は JavaScript>>>>googleのV8チーム なのだから、
世界レベルで最適化するのであれば、最初からV8が対応すればよかっただけの話だ。
メモリリークが問題になるほどの状況になったら、遅いけど完全なGCで回収すればよかった。
これは再帰で組めるので、100行程度で実装できる。
それをせず、世界中のJavaScriptエンジニアに醜い対策コードを書かせるという判断を下したgoogleは技術力が低い。
だから、彼らの判断は信用に値しない。
実際にインスタンスツリーを構成すると、クラスツリーと同程度の見にくさ以外の問題点は無い。
見にくさだけを問題として「止めとけ」というのならクラスツリーも止めるべきだ。
（これはクラスシステム全否定になるから出来ないとして、
だとすると、クラスに慣れているエンジニアにとってはインスタンスツリーも問題ないはずだ。）
ただ、俺がまだ気づいていない問題点があるのかもしれない。だから聞いている。
言い換えれば、俺が無知なだけか、googleの判断ミスかを確認しようとしている。
説明を理解できないのは俺の問題だが、説明が出来ないのはgoogleの問題だ。
googleの言及は見やすさだけだ。ならばコード/フットプリントを優先するならやってもいい範囲だと俺は判定する。
実際にクラスシステムは同様に見にくいのだから。
- 721 ：デフォルトの名無しさん：2015/07/23(木) 22:16:24.86 ID:6SZxWA2I
- 全面的にhidden classを作るなんてことはしない
それ自体がオーバーヘッド大きいから
V8の場合はnew Ctor()の呼び出しではhidden classを作るがリテラルやObject.create()では作らない
たしかSpiderMonkeyも同じ
処理系は一般的な書き方をしたコードで大きな効果が得られるように最適化する
一般的な書き方ってのはコンストラクタを使ってnewするクラスベースの書き方
「処理系はクラスベース前提に最適化」ってのはそういうこと
- 722 ：デフォルトの名無しさん：2015/07/23(木) 22:28:28.44 ID:mEZw2Q+n
- オーバーヘッドが大きいから作らない。
というのは考え方がおかしい。
オーバーヘッドの話をするならば
関数呼び出しをするだけでも
オーバーヘッドが有る。
要するにオーバーヘッド以上のメリットがあればいいわけで
それは一律に決まるものではなく場合によって変わる。
メリットと比較しないで結論を出す考えは
思考停止してるのと同じである。
- 723 ：デフォルトの名無しさん：2015/07/23(木) 22:38:02.91 ID:6SZxWA2I
- 面倒くせー
リテラルやObject.create()では総じてhidden classを作るオーバーヘッド(デメリット)の方が大きいから作らない
んなもん散々検証して判断してるに決まってるだろうが
この程度補完して読めないなら2ch向いてねーよ
一から十まで丁寧に書くやつならブログ書いてるっつーの
つかそろそろ読むのも面倒な長さだし
- 724 ：デフォルトの名無しさん：2015/07/23(木) 23:00:40.95 ID:UCOFR8WX
- >>721
それは多分間違いだ。
理由は、new だけをターゲットにするのなら、この構造は明らかに不適だからだ。
new の場合は最初からメンバが全面的に決まる。
つまり、C0,C1と継承していくのではなく、最初からC1を作る方がいい。しかし、そうなっていない。
> https://developers.google.com/v8/design (再掲719）
また、classなら、後からプロパティが追加されることもほぼ無い。
この「後から追加されない」前提なら話がすごくシンプルになるので、これを利用しない手は無い。
この場合、普通は、後から追加されればシンプルに「捨てる」という実装が取られる。
実際は、z というプロパティを追加したら、新たに hidden class が生成されている。
> http://www.html5rocks.com/en/tutorials/speed/v8/?redirect_from_locale=ja
もし本当に new のときだけ hidden class を使用するにこの実装なら、間抜けすぎる。
googleは糞だという判定ではあるが、さすがにそこまではひどくないと見ている。
実装自体は全面的に hidden class を使う気がある感じだ。
もしこの実装で本当に new でしか使えないのなら、それはバグっていてリリースできないだけだ。
>>723
> んなもん散々検証して判断してるに決まってるだろうが
これは何をやったんだ？ベンチマークか？
new の場合とオブジェクトリテラルとの速度比較で検証は出来るが。
- 725 ：デフォルトの名無しさん：2015/07/23(木) 23:42:47.23 ID:UCOFR8WX
- 訂正
× つまり、C0,C1と継承していくのではなく、最初からC1を作る方がいい。
○ つまり、C0,C1,C2と継承していくのではなく、最初からC2を作る方がいい。
>>721
ちなみにその他の実装面については俺は同意する。
オーバーヘッドはそこそこあるだろうし、
クラスベース記述が先に最適化されることも妥当だろう。
JavaScriptの世界でクラスベース記述が標準なのかは俺は知らない。
- 726 ：デフォルトの名無しさん：2015/07/24(金) 06:47:59.61 ID:12UqcE6d
- オーバーヘッドがそこそこって
一体どれくらいだよｗ
具体的な計測もせずに
パフォーマンスを語るな
初心者だぞそれ。
- 727 ：デフォルトの名無しさん：2015/07/24(金) 09:26:15.15 ID:qwe2hlrV
- >>713
全く唯一の方法ではないんだが何言ってんだこいつ
Reflect.construct使えばできるだろ
それにそれ使わなくとも現状結局はnew.targetはプロトタイプの設定にしか使われてないから
自前でそれやりゃ同じこと
糖衣構文だよ
- 728 ：デフォルトの名無しさん：2015/07/24(金) 20:13:30.42 ID:Q/qDEZvi
- これどう思う？
左辺値に干渉できるのは新しいけど……
https://esdiscuss.org/topic/extensible-destructuring-proposal
- 729 ：デフォルトの名無しさん：2015/07/24(金) 20:48:56.48 ID:CcVApBxd
- パターンマッチがないから50点
- 730 ：デフォルトの名無しさん：2015/07/24(金) 20:50:15.97 ID:4a0VCJwf
- 一応まとめておくと、
【質問】
・多層継承って何か問題ある？(>>686)
【回答】
・理解するのが難しくなるだけ。動かなくなることは無い。(>>687)
・オブジェクトコンポジションのほうがいい(>>688)
・5-6階層なら普通に使っている(>>695)
これについてはこんな感じか？
他あればよろしく。
- 731 ：デフォルトの名無しさん：2015/07/24(金) 20:59:24.53 ID:CcVApBxd
- 蒸し返さなくていいから
- 732 ：デフォルトの名無しさん：2015/07/24(金) 21:47:41.91 ID:Q/qDEZvi
- 継承とはいうもののJSではただチェーンが伸びているだけだから
別に大層なものでもない
- 733 ：デフォルトの名無しさん：2015/07/24(金) 23:07:46.30 ID:4a0VCJwf
- >>732
それは他言語も同じようなものだと思うが。
すまんが728については俺はパス。
JavaScript暦半年の俺は、まだその域に(ry
- 734 ：デフォルトの名無しさん：2015/07/25(土) 00:16:03.23 ID:DSYM6T2c
- >>727
> 糖衣構文だよ
糖衣構文すばらしいよね。
なくてもできるんだけど、あれば可読性が
大幅に向上する。
アセンブラから見れば、言語の機能なんて
全部糖衣構文なわけで、それがあるから
生産性を上げることができる。
- 735 ：733：2015/07/25(土) 02:33:04.54 ID:nH18/T+5
- >>728
一応素人なりの答えを書いておく。
JavaScriptは（というよりも最近の流行りか？）糖衣構文が多いように感じる。
理由は多分3つあって、
1. ユーザーが使いやすいから
2. ソースのバイト数を少なく出来る
3. JITが取り扱いやすいから
だと思う。2,3はJavaScript特有の動作環境によるものだ。
JITなら余分な物は書かない方がいいので、Mapのdestructuringについてもサポートされた方が3.は成立する。
最初のGitHubと記事の1/3は読んだ。
そしてJavaScriptの仕様を決めている連中は相当糞だというのが分かった。
ここまで酷いとおそらく政治的なものだと思うが。（多分Java)
- 736 ：733：2015/07/25(土) 02:33:56.76 ID:nH18/T+5
- 表面的な問題点は、Mapのキーがオブジェクトのときにdestructuring出来ないということだ。
これに対する最適解は、オブジェクトリテラルで書ければいいだけだ。
これは、JSON.stringifyと同様、キーもクオートすれば解決する。クオートが無ければ変数扱いだ。
これが一番直感的で美しい。
var a = { b: 'c' }; // 従来のオブジェクトリテラル、キーはString前提
JSON.stringify(a); //
{"b":"c"} // キーもクオートされる、この書き方をしてもらう
もちろんこれだと後方互換性に問題がある。
だからそれをどうするかを考えるのがワーキンググループ(WG)の役目だ。
多分<>は使われていない気がするので、最悪、以下でいい気がする。
(<ES6>で拡張オブジェクトリテラル、被るようなら<<<ES6>>>とか、被らなくなるまで増やす。）
var a = { b: 'c'}; // 何もつけなければ従来のオブジェクトリテラル、aはただのオブジェクト
var d = <ES6>{ a: 'f', 'g':'h'}; // dはMap、キーaはオブジェクト、キーgはString
この前提で読んでいたら、GitHubの話があまりに意味不明なのでMapを見ると、
なんとMapは[]でプロパティアクセスできず、get/setでアクセスするという糞仕様。
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
これでは従来のJavaScriptとあまりにもかけ離れている。仕様策定者は死ねと言われるレベルだ。
本来、Mapも従来と同様、上記の例を引き継ぐなら、
d[a] // 'f'
d['g'] // 'h'
でよかった。これは通常のオブジェクトと全く同じアクセス方法になる。
- 737 ：733：2015/07/25(土) 02:35:07.83 ID:nH18/T+5
- 結果、俺の拡張は、
・<ES6>{}
の拡張オブジェクトリテラル一つで全て従来どおり整合性を保ち直感的、
もちろんdestructuringも出来るのに対し、
ES6のWGがやったことは、
・従来の記述でアクセスできないMapを作成し、
・不整合な仕様を導入したからMapにdestructuring出来ない
(そしてこの状況を打開するために Symbol.get() が必要だという主張）
という、馬鹿かよとしか言いようが無いものだ。(泥縄ではなくマッチポンプだこれは)
ただこのレベルの馬鹿が仕様策定WGに入ることは通常ありえないので、これは多分政治的なものだ。
見る限りJava陣営がJavaScriptを壊しにかかっているように思える。
（JavaScriptのJava化、多分ポーティングを楽にするため)
- 738 ：デフォルトの名無しさん：2015/07/25(土) 02:44:49.94 ID:nH18/T+5
- ちょっと変なところで改行されてしまったが、736は
JSON.stringify(a); // 結果は {"b":"c"} // キーもクオートされる、この書き方をしてもらう
ということでよろしく。
- 739 ：デフォルトの名無しさん：2015/07/25(土) 04:36:01.08 ID:COqauPRB
- なんかずれてないか？
Mapが[]でアクセス出来ないのはkeyに文字列以外も取るから当たり前。
もっと簡潔にアクセスしたければAbstract Referencesのような新たな演算子が必要。
そしてMapにdestructuring出来ないという話ではなくて、Mapをdestructuring出来ないという話。
- 740 ：デフォルトの名無しさん：2015/07/25(土) 04:41:24.51 ID:WBKPsbT0
- 文字列どうこうは関係ない
MapもObjectだから普通のプロパティを持つってだけ
map['size'] // property
map.get('size') // key/value
- 741 ：デフォルトの名無しさん：2015/07/25(土) 07:15:25.55 ID:Q65ZCebZ
- うむ。JavaScriptは
全てがオブジェクト。
素晴らしい。
- 742 ：デフォルトの名無しさん：2015/07/25(土) 08:03:16.03 ID:X7A7gMEV
- >>736
> 表面的な問題点は、Mapのキーがオブジェクトのときにdestructuring出来ないということだ。
> これに対する最適解は、オブジェクトリテラルで書ければいいだけだ。
さすがにこれはおかしい
下記コードは当然、独立して値を保持するが、オブジェクトリテラルにしたら a === b と扱われて上書きされる
Object 型が Reference 型である事に留意すべきだ
var a = {}, b = {}, map = new Map;
map.set(a, 'hoge');
map.set(b, 'foo');
console.log(map.get(a)); // "hoge"
console.log(map.get(b)); // "foo"
>>740
関係ある
ES6 でオブジェクトの key に指定可能なのは String 型、Symbol 型だけであり、Object 型は指定できない
上述のコードでは map[a] のようなアクセスは出来ない
- 743 ：デフォルトの名無しさん：2015/07/25(土) 08:22:47.53 ID:d/AWyVXj
- 仮にMapのキーが文字列だけに制限されてたとしても[]は使えない
という意味で関係ない
- 744 ：742：2015/07/25(土) 08:22:48.26 ID:0SHWVaxG
- 言葉足らずだったので補足
> 上述のコードでは map[a] のようなアクセスは出来ない
Map の仕様にないというだけでなく、プロパティアクセス演算子の仕様で key に Object 型を指定できない
var a = {}, obj = {};
obj[a] = 'hoge'; // プロパティに Object 型は指定できない
- 745 ：デフォルトの名無しさん：2015/07/25(土) 08:42:21.70 ID:d/AWyVXj
- これなら分かるか？
> let map = new Map([['size', 100]])
undefined
> map['size']
1
> map.get('size')
100
- 746 ：デフォルトの名無しさん：2015/07/25(土) 11:50:30.68 ID:nH18/T+5
- >>739
ああ、確認しよう。
> Mapが[]でアクセス出来ないのはkeyに文字列以外も取るから当たり前。
俺はこれが駄目で、元凶だと思う。
(ドット記法は出来なくていいが、ブラケット記法は提供しなければならない）
> もっと簡潔にアクセスしたければAbstract Referencesのような新たな演算子が必要。
[]で全てアクセスできるように整備すれば、これは不要。
今はそれが出来ていないから、Symbol..XXXを使っているように見える。
パッチのパッチという最悪のことをやっている。しかも仕様でね。言語を殺そうとしているとしか思えない。
> そしてMapにdestructuring出来ないという話ではなくて、Mapをdestructuring出来ないという話。
同じだよ。Mapをdestructuringするためには、左辺側にリテラルでMapを記述できないと駄目。
それが出来ないという話。
- 747 ：デフォルトの名無しさん：2015/07/25(土) 11:52:27.45 ID:nH18/T+5
- >>740
>>745
'size'がこれだと予約語扱いになってしまうので、プログラミング時に邪魔だ。
だからこれはSymbol.sizeにするべきだった。ここら辺も仕様が糞だ。
map[Symbol.size] // サイズを返す。
map['size'] // 'size'というStringキーがあれば、valueを返す。（今はサイズを返す仕様。マジで糞。）
というか、ES6のMapは結局従来オブジェクトにメソッドを実装しただけのものだ。
これなら、ES5でmap.jsとして提供できるものだ。仕様として糞を入れるのは毒でしかない。
ES6として入れるのなら、[]アクセスを提供して使いやすくしないといけない。
([]アクセスの提供はmap.jsでは出来ない。
proxyを使えば本来は出来るようになるはずだが、この感じだとproxyも使えない仕様の可能性が高い。）
>>742
> オブジェクトリテラルにしたら a === b と扱われて上書きされる
ならない。=== が成立しないから。
var a = {};
var b = {};
a===b; // false
なっている実装があるとしたら、それは実装側のミスだ。
高速化のために CopyOnWrite で実装しているのだが、 === についての対策を忘れている。
というか、お前らはこの仕様で何も思わないのか？
俺が上司ならES6WGは即刻全員首にする。そして仕様を練り直す。
それぐらいこの仕様は酷いぞ。
- 748 ：デフォルトの名無しさん：2015/07/25(土) 13:54:48.64 ID:Q65ZCebZ
- 仕様が全てじゃないからなぁｗ
重要なのは互換性だよ。
互換性を打ち切るだけの理由がない。
それがわからない時点でお前はクビだ。
- 749 ：デフォルトの名無しさん：2015/07/25(土) 13:58:51.47 ID:Q65ZCebZ
- あ、ごめん
クビ以前にES6WGに
参加する力がなかったかｗ
- 750 ：デフォルトの名無しさん：2015/07/25(土) 16:35:04.47 ID:LJEH9gC5
- 本気ならこんなとこで吠えてないでes-discuss行ってこいよ
- 751 ：デフォルトの名無しさん：2015/07/25(土) 17:35:12.66 ID:VFfveOXZ
- Symbol.sizeなんて作ったら、それだけマップのキーにできなくなるから、やっぱり変じゃないか？
Map.getSize(map)とかにするならまだ分かる
- 752 ：デフォルトの名無しさん：2015/07/25(土) 18:11:32.25 ID:vL98DgZL
- []を拡張してProxy的な事ができるようにしようという案はstrawmanで昔からあるよ
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
ここでは.は従来のままで[]記法だけハック出来るようにすることで、
Mapのサイズを知りたければmap.sizeとできるし、JITエンジンにも比較的優しくなっている
まあでもぶっちゃけ演算子オーバーロードに近いしそこまで大層で闇を生みそうなものにしていいのかってのはある
どうせ入れるのならAbstractRefのように真新しい構文でやった方がいいと思うけどね
- 753 ：デフォルトの名無しさん：2015/07/25(土) 18:34:14.83 ID:nH18/T+5
- >>751
Symbolは列挙体だ。
だから通常はそこを指すことはしないし、出来なくてもまったく問題ない。
C#の列挙体は以下例の FileAccess.Read とかで、実体はビットフィールドのマクロだ。
https://msdn.microsoft.com/ja-jp/library/4z36sx0f(v=vs.110).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-1
JavaScriptでも同様の使い方を想定しているはずだが、
確かに仕様を見る限りなぜかローカルSymbolラッパは作れるようなので、
そちらの言う様にメソッドとして実装したほうがいい。
>>747 修正
Map.prototype..getSize() // サイズを返す
Map['size'] // 'size'というStringキーがあれば、valueを返す。（ES6はサイズを返す仕様。）
- 754 ：デフォルトの名無しさん：2015/07/25(土) 18:47:54.44 ID:nH18/T+5
- >>751
すまん、753は間違い。
JavaScriptはメソッドとプロパティも区別してないから、完全に別物として実装するしかないね。
prototypeには入れられない。完全にそちらの指摘どおりになった。
>>747 再修正
Map.getSize(map) // サイズを返す
Map['size'] // 'size'というStringキーがあれば、valueを返す。（ES6はサイズを返す仕様。）
- 755 ：デフォルトの名無しさん：2015/07/25(土) 18:51:38.87 ID:qGUo5/ZS
- まあでもMapがその仕様なら分割代入の拡張だって必要なかったっと言っても、
結局[]の拡張だって、ほぼMapのためだけのものとも言えるしね
でも実際はMapを除いても分割代入の拡張は便利なものであるだろうし、
[]の拡張だってそうだろうから、これらの議論とMapの仕様の是非の結びつきはかなり弱いと思うし、
どちらのMap仕様が絶対良いと言えるようなものではないと思う
- 756 ：デフォルトの名無しさん：2015/07/25(土) 19:01:12.92 ID:qGUo5/ZS
- instanceofの前例から見るに、高レベルな演算子のオーバーロードを
シンボルプロパティによるハックでやっていくっていうのは今後の基本方針だろう
でも、==や<=のような低レベルな演算子はもっと限定的で低レベルな記述で
オーバーロードするというのが今のところの雰囲気
そこで[]はその中間に当たるからなんとも微妙なんだよね
まあ１つだけ言えることは、これはES6を入れる際に一緒に持ってくるには
大きすぎる問題だったけどMapは欲しかったから、今のMapの仕様になったのは妥当だと思う
別に[]の拡張が入ったからといっても今のMapがダメダメになるわけでもないし、
AbstractRefや分割代入の拡張という、筋の良い案でいくらでも諸問題に対するフォローは効く
- 757 ：デフォルトの名無しさん：2015/07/25(土) 19:23:19.86 ID:nH18/T+5
- >>752
すまんがちょっと読む気にならない長さなので頭1/5位だけ読んだ。
> let obj = {
> [pname]: function() {}
> };
これって今書けるんだっけ？書けるんだったらこれでいい、というか、
function Map(){
get: function(x) {return this[x];}
[]: function (x) {return this[x];} // これを追加
}
でMapに[]アクセスを実装すれば幸せに終了だ。
この記述がproxyで出来るのなら、ES5でMap[]を提供するMap.jsがかけるはず。（Proxy自身がES6ではあるが）
それとは別に、ドット記法とブラケット記法の問題はあって、
冗長なのは事実だから、モード変更(strictモードみたいなものを別に作る）とかで切り替えてしまうのがいいと思うけどね。
あれが無ければもっと速く動かせる。
- 758 ：デフォルトの名無しさん：2015/07/25(土) 19:30:20.09 ID:nH18/T+5
- >>755-756
ちなみにMapの問題は単純で、
ES6： Mapを別物として実装する。
俺： 全オブジェクトをMapにする。
ということ。Mapを導入するのではなく、オブジェクトのキーがString限定だったのを解除する。
全てをMapで扱い、後方互換のために従来記法のオブジェクトリテラルについてはキーをString限定とする。
ES6は拡張の方向を完全に間違っている。
今後Mapのリテラルを導入するとしたら、完全に重複だよ。
Mapが[]でアクセスできるのは結果的にであって、[]でアクセスするために何かを導入するわけではない。
- 759 ：デフォルトの名無しさん：2015/07/25(土) 20:59:45.45 ID:qGUo5/ZS
- >>757
大事なのは「The New Semantics of [ ]」のところから
その記法はES6で有効
だが[]:はちょっとナンセンスだと思う
[]:→[undefined]:→"undefined":にも見える
やはりシンボルでするしかないだろう
>>758
全オブジェクトをMapにすると言っても過去の互換性を守るにはシンボルの追加のように
オブジェクトはオブジェクトのままで、扱い方を追加して解決するしかない
結局シンボルでフックしてWeakMapでゴニョゴニョやる以外にない
それなら既存のものを変革させなくともAbstractRefのように専用のものを作ったほうがいいのではないか？
[]の拡張と比べてAbstractRefの筋の良い所は、元の仕様の１つの名前がRelationships
http://wiki.ecmascript.org/doku.php?id=strawman:relationships
だったことからも分かる通り、２つの物の関係についての扱いを表わせられること。
どうしても[]だとオブジェクト指向のしがらみから逃れられず、
オブジェクトと、オブジェクトに送るメッセージという結構偏った関係になるが、
AbstractRefだとそれよりは対等で、気分的にもより汎用的で自由な使い方ができる記法となっている
- 760 ：デフォルトの名無しさん：2015/07/25(土) 21:10:55.01 ID:mmveDVXC
- >>747
結局、あなたは>>742をどうやってブラケット記法で表現しようとしているのかな
オブジェクトリテラルで書けばいいだけは map['{}'] のような表現しようとしていると思っていたが、違うようだ
あなたが理想とする map でアクセスするコードを示して欲しい
- 761 ：デフォルトの名無しさん：2015/07/25(土) 22:00:48.14 ID:nH18/T+5
- >>759
追加で少し読んだ。
要するに内部的に別オブジェクトにストアし、読み出し時にフックして読込先を切り替えようということだろ。
記述できるのならありだと思うよ。
[]:がナンセンスなのは認める。あれは通じればいいと思って書いているだけだから。
それを分かりやすい記述方法に練るのがWGの仕事だ。
影響範囲が分からないので安全範囲だけに限定して変更しました、
もちろん重複はあるし冗長になったけど安全のためには仕方ないよね、というのは、
コピペプログラマと同じだ。死ねでいい。
これを仕様でやったら取り返しが付かなくなる。もう遅いが。
影響範囲を見切れないやつが仕様をいじっている時点で最悪だ。
すまんが @ 演算子が何をやりたいのかわからない。（それ以前に何が問題かも知らないのだが）
ただ、俺ならObjectもMapもWeakMapも同じで、キャスト演算子<ES6_Weak>を用意して対応する。(弱参照化キャスト）
var a = { b: 'c'}; // キーbはString
var d = { e: 'f'}; // キーeはString
var g = <ES6>{ a : 'h', <ES6_Weak>b: 'i', 'j':'k'}; // キーaはオブジェクト、キーbはオブジェクトだが弱参照、キーjはString
// つまりMapとWeakMapを混合可能、キーに限らずvalue側にも弱参照を使えるようになる。
従来オブジェクトについては、「キーを常にtoStringしてから使う」で対応できる。
後はMapもWeakもObjectと同じインタフェースにする。（今回新たに追加なのだから、自由に出来る）
ただ、キーを常にtoStringするオブジェクトかどうかは内部的に値を持っておく必要がある。（これは実装側）
これなら使い方はすっきり従来どおりだ。
後は<ES6>と<ES6_Weak>をどう書くかをWGが考えればいい。
> どうしても[]だとオブジェクト指向のしがらみから逃れられず、
俺はただの連想配列としか思っていないけどな。
- 762 ：デフォルトの名無しさん：2015/07/25(土) 22:00:56.60 ID:paoVPCKX
- あとそれをECMA Internationalに
提案して欲しい。
- 763 ：デフォルトの名無しさん：2015/07/25(土) 22:01:25.02 ID:paoVPCKX
- >>761
> それを分かりやすい記述方法に練るのがWGの仕事だ。
あんたの仕事だろう？
- 764 ：デフォルトの名無しさん：2015/07/25(土) 22:07:06.65 ID:nH18/T+5
- すまん間違えてる。
var a = { b: 'c'}; // キーbはString
var d = { e: 'f'}; // キーeはString
var g = <ES6>{ a : 'h', <ES6_Weak>d: 'i', 'j':'k'}; // キーaはオブジェクト、キーdはオブジェクトだが弱参照、キーjはString
// つまりMapとWeakMapを混合可能、キーに限らずvalue側にも弱参照を使えるようになる。
分かる範囲だが、3行目のキーは d だ。（リテラル内とコメントの計2箇所）
- 765 ：デフォルトの名無しさん：2015/07/25(土) 22:40:43.14 ID:F8EjZDFb
- >>761
問題がget等のメソッド使うのが野暮ということなら
今話してるmap[val]をval@mapと表せられるのがRelationships
それに(this)bind演算子を合体させたのがAbstractReferences
https://github.com/zenparsing/es-abstract-refs
これであればプライベートの変数pがthis.pの代わりにthis::pで表される
こういうのを[]の拡張でスマートに行うのは難しい
何故ならthis[p]はthisが主体であるが、this側が情報と制御を握っているという構造は
本当はプライベートがない上でプライベートを再現するのには向いていないからだ
その点this::pでは、p側にthisが渡されるためにとても自然でクリーンに実現できる
pがそのクラスのpプロパティのキーになるということも、pをprivate symbolかのように見ることが出来てJS的に自然に受け入れられる
ではp自体はどのように処理を作ればいいかというと、実はこれはWeakMapそのままでいい
あとはpを簡単に作れてそのクラスだけに結び付けられれば言うことがないので、
ここはせっかくとっておいたprivateキーワードを使えばJSのプライベート事情がとてもスマートに簡潔する
- 766 ：デフォルトの名無しさん：2015/07/25(土) 23:07:52.90 ID:nH18/T+5
- >>765
読み直したわけではないが、その説明で分かった。
逆参照を導入して、これは強参照ではまずいから弱参照、
だったらprivateを導入できるんじゃね？って話か。そしてその実装が書いてあると。
それはMapとはまた別の話だ。
俺の見解は、
・逆参照は今のところ欲しいと思ったことが無いから分からない。ただ、すごく便利なら導入はありだろう。
・privateは正直、普通のclassシステムをそのまま導入した方がいい。それがみんなの望みだし。
今のJSにクラスを無理に乗せようとしているからおかしなことになっている。
クラスが要るのなら、本物のクラスを導入すればいいだけだ。
ここら辺のせめぎあいは正直よく分からない。
(逆参照の導入目的がprivateなら、最初からprivateを導入した方がいい)
どーでもいいが、@よりは <- の方が分かりやすい気はするが。
Mapについては、JSは配列っぽいものは全て[]でアクセス可能で来ているのだから、
Object[]
Array[]
String[]
Map[] <- なぜこれが出来ない？
という話。他と揃えないと分かりにくくなるだけ。
- 767 ：デフォルトの名無しさん：2015/07/26(日) 04:39:17.48 ID:wzLqUrKS
- 本物のクラスといっても、JSはプロトタイプベースであり、
プロトタイプベースの方がクラスベースよりも原始的（低レベル）なのだから
あくまでプロトタイプベースの糖衣構文として組み立てていく道以外は難しい
そしてAbstractReferences自体が弱参照とかそういう話ではない
これは汎用的な構文で、今まで話してきたような「f[@@get](v)」を「v::f」の糖衣構文として書けるということ
但し、順番が逆なことでいろいろと都合もいいという話
privateだけではなくthis_bindとかいろいろな用途に使える
それから正直JSerはany[obj]はany[obj.toString()]となると直感的に染み付いてるから
Mapのような挙動で[]を使わされるのはむしろ大きな違和感がある
今のMapの仕様はES5でも簡単に再現可で、仕様から実装も透けて見えJSerには自然に受け入れられる
- 768 ：デフォルトの名無しさん：2015/07/26(日) 08:47:51.21 ID:ktgdD6Ic
- >>747
> map[Symbol.size] // サイズを返す。
つまり、あなたは Map.prototype にあるプロパティ全てを Symbol.*** で指定すべきと考えているわけだな
[[Prototype]] にあるプロパティも当然、Symbol 型にしなければならないな
document.all のようにnew Map だけ意図的に ECMAScript に違反する仕様を強いるわけだな
ユーザはある不明な Object 型を処理をする場合、new Map だけ特別な処理をするように考えなければいけないのだな
ところで、 Symbol.size は Undefined 型だな
Symbol の使い方を知らないのかね
- 769 ：デフォルトの名無しさん：2015/07/26(日) 08:56:31.41 ID:Lmm8STAE
- 補足すると、低レベル＝機械語
高級言語（今普通に使われてる言語）は、機械語から
発展して様々なわかりやすくて使いやすい文法（＝糖衣構文）を追加したもの。
機械語と同様、低レベルな方がいろんなことができるのだが
その半面使い方が冗長で難しくなる。
クラスに関してはクラスという文法がある言語に比べればJavaScriptは低レベル。
似たような言語としてPerlもある。だから使いやすくするために、糖衣構文を追加する。
もっとも糖衣構文ではなくてもライブラリを作ることでほとんど同じことは可能。
それがGoogle Closureのgoog.inheritsだったりUnderscore/lodashのextendだったり、
nodeのutil.inheritsだったりするわけ。
- 770 ：デフォルトの名無しさん：2015/07/26(日) 09:05:50.58 ID:WE6uU2++
- 文が長くてあんまり読んでないけど，仕様に不満があるんだったらes-discussで問題提起してくればいいじゃん
こんな辺境で滔々と自説をぶちあげられてもなあ
- 771 ：デフォルトの名無しさん：2015/07/26(日) 09:19:48.46 ID:JNDXJIaM
- >>766
String[obj]とかArray[obj]はobjがToStringされてからアクセスされて、
Map[obj]ではToStringせずにアクセスしたいんだと思うんだけど、
Map[]を用意しても他と挙動が揃わないよね
- 772 ：デフォルトの名無しさん：2015/07/26(日) 09:57:06.37 ID:MwjqrYs0
- まあ適当な意見でes-discussに突入しても鼻で笑われるだけだろうから、
このスレで自分の意見を練りなおすのは良い心がけだと思うよ
- 773 ：デフォルトの名無しさん：2015/07/26(日) 10:17:57.89 ID:0BoySehE
- 単発IDで誰が誰かわからないんでコテつけてくれませんかね
- 774 ：デフォルトの名無しさん：2015/07/26(日) 10:53:28.82 ID:Lmm8STAE
- じゃあ言い出しっぺのお前から
- 775 ：デフォルトの名無しさん：2015/07/26(日) 16:21:32.88 ID:xC59A2FG
- ここは2chだ。便所で吠えるのは勝手だが便所で吠えるなとたしなめる奴は便所だということをわきまえろ
- 776 ：デフォルトの名無しさん：2015/07/26(日) 17:05:40.22 ID:+ERJEYbW
- 別に互換性を狂わすようなアイディアを出すなというわけではないが、
そうなったらもはやESではなくて別言語だよねというようなものを普通に主張されても困る。
- 777 ：デフォルトの名無しさん：2015/07/26(日) 17:29:04.51 ID:D4pJLnwj
- 便所だとわきまえてるなら吠えずに落書きで済ませろよ
せめて「ぼくがかんがえたさいきょーのえくますくりぷと」スレで吠えてろ
- 778 ：デフォルトの名無しさん：2015/07/26(日) 21:52:10.80 ID:+ERJEYbW
- ここで主張してくれて構わないんだが、
ES4失敗からの互換性重視、拡張重視の流れがあるということくらいは
せめて知ってから発言してくれないと正直ドン引く。
例えばクラスベースの導入はSane/SoundScriptみたいに、
別モードの導入が現実的な限界。
- 779 ：デフォルトの名無しさん：2015/07/26(日) 22:37:35.22 ID:CUGdI6EM
- >>767
> あくまでプロトタイプベースの糖衣構文として組み立てていく道以外は難しい
> 今のMapの仕様はES5でも簡単に再現可で、仕様から実装も透けて見えJSerには自然に受け入れられる
多分ここら辺の感覚が違うんだ。
俺は、ES5でエミュレーションできるのならMap.jsとして提供すべきで、仕様を追加する必要はないと考える。
ただ、jQuery等も含め「今既にあるもの」から仕様を取り込んできたJSとしては、そちらの言う感覚の方が自然で、
Map.jsを本体に取り込んだということなのだろう。
たぶんJSは仕様の意味が軽い。そして本質的な改訂が為されていない。
C#は3.0でLINQとラムダ(クロージャ）を導入した。本当に言語側からのサポートが必要なら、やるしかない。
(ただしC#は完全上位互換、つまり過去のコードはこれでもそのまま通った)
クラスが欲しいけど言語側からのサポートがないから永遠とクラスモドキ、というのは全くの無駄だ。
要るのなら導入すべきで、要らないのならすっぱりあきらめるべきだ。(個人的にはプロトタイプで問題ない)
必要なのはクラス構文そのものではなく、動的保護なのだろうし。
- 780 ：デフォルトの名無しさん：2015/07/26(日) 22:38:24.89 ID:CUGdI6EM
- 仕様の改訂は当たり前だが最小限に済ませるべきだ。そして整合性は最大限に保たないといけない。
Mapの導入経緯は、「objをキーに出来ない」であり、元々Objectのパッチだ。
そしてさらにそれ用の仕様、Symbol.xxxってのは、パッチのパッチになる。（ただし列挙体の導入はいずれ必要だが）
これをやりだすとゴミ仕様が膨らんでゴミ言語になっていく。
元々の問題点、「objをキーに出来ない」を直接解決するのが正しいやり方だ。
そもそもキーのtoString()仕様は捨ててもいい類のものだ。実際 [Object Object] であり、使い物にならなかった。
だからパッチ当てで後方互換を確保しておけばそれで十分だ。(今後ともパッチのパッチが必要とはならない）
新しくJSを使う人にとっては、Map[]で何の問題も感じない。最初からそうあるべきだった。
オブジェクトリテラルの書き方についても、最初からJSONと同じでよかった。（キーがStringであることを明示）
元々の仕様に不備があったからおかしなことになっていたので、それを訂正するということ。
結果、矛盾は解消、仕様は小さくなる方向だ。
【ES6仕様】
Objキーは常にtoString()
MapキーはtoStirng()なし、ただし[]アクセスできず
Symbol.xxxを導入
【Objキーは生仕様】
Objキーは生で使う、よってMapは不要
(後方互換性のためにパッチを用意する)
- 781 ：デフォルトの名無しさん：2015/07/26(日) 22:39:02.52 ID:CUGdI6EM
- 仕様もプログラムと同じで、新機能が欲しいときに、パッチを当てるか、思い切って書き直すかを選択しないといけない。
ただ、言語仕様についてはもっと原理的で、パッチすら当てないほうがいい。
今のJSの仕様だと確実に迷走する。この先JSは死ぬことになるだろう。
集団指導体制なのかは知らないが、その悪い点が出ている。無難な選択しか出来ず、決めきれていない。
この先、新しいプログラミングパラダイムが出現したとき、取り込むという決断を出来ずに死ぬ。（今のJava）
JSの優位点はJSそのものではなく、ブラウザで動く点だ。だから、逆に言えば、ブラウザに他言語が搭載されれば廃れる。
Dartはこれを目指して失敗した。後はTypeScriptだが、あれは置換は狙っていないようだ。
クライアントサイドはしばらく揺ぎ無いだろうが、サーバサイドは自前で決められるので、乗り換えはしやすい。
サーバサイドで実績を積んだ言語が載り換わってくることになるだろう。
- 782 ：デフォルトの名無しさん：2015/07/26(日) 22:40:01.24 ID:CUGdI6EM
- >>767
> そしてAbstractReferences自体が弱参照とかそういう話ではない
ああ、これは理解している。
> 但し、順番が逆なことでいろいろと都合もいいという話
一応半分以上読んでみたが、やはりよく分からない。
x@r=y自体に使い道があるのならいいが、r[x]とx@rの違いでフックしたいだけなら、ただのゴミだ。
ライフタイムがx>rのときにフィットするというのは確かにそうだが、
それはHaskellの遅延評価みたいに全面的にx@rしか許さない状況で試してみないと分からない。
APIを全部見せたくないというのは、
publicが上書き放題な今のクラスモドキをクラス（動的保護つき）にすればいいだけだ。
俺はクラスを多用していないのでbindのありがたみはあまり分からないが、
内部から呼ぶときにはthisが変わってウザいのは確かだ。
とはいえ、::は他言語だと単にクラス階層という印象があるが、bindまで絡めると余計に分かりにくくならないか？
あと、PrivateFieldsとAbstructReferenceは直接関連はなさそうに見えるが、、、
- 783 ：デフォルトの名無しさん：2015/07/26(日) 22:51:06.49 ID:7EBqSyeY
- Java死んでないし、TypeScriptは死んだ。
JavaScriptが今まで生き延びた理由を説明できないだろう。
- 784 ：デフォルトの名無しさん：2015/07/26(日) 23:04:38.16 ID:OcTVoTNp
- そんな事言い出したら構文レベルでない物は全て不要になると思う。
それこそDateやMathだって別にライブラリとして作れるんだし。
でもあって便利だからあるのは間違いじゃないと思う。
そしてジェネレーターなんかの新構文だってES6to5トランスレータがしてるように
switchなんかで再現するのもそう難しくないし、多くが糖衣構文で別に重いものでもないともいえる。
そもそも当然ES1の頃からチューリング完全なんだから、
後はどれだけ世の中の要求に合わせて便利にしていくかということしかないだろう。
そしてMapだけ[]を特別視するというのはメリット少ないし、筋が良くない。
１つ言うとmap[]で他と揃うと言うが、そうは思えないんだが仮にそこの面はそうだとしても、
他方でSymbolかMap.getSize(map)のような存在や手法を入れないといけないのは
今のmap.sizeと比べるとけして他と揃っているとも言えないし、不自然だ。
それらの特別なルールをいくつも入れて生まれると主張している自然性とメリットは、
同じく生まれざるを得ない不自然性とデメリットによって相殺されている。
総合的に見てmap.get、map.setという作りが簡単なAPIである方が良いと思う。
もしどうしても[]をどうにかしたいのなら、
Dartのように演算子オーバーロードとしてより汎用的な仕組みを入れた方がいい。
- 785 ：デフォルトの名無しさん：2015/07/26(日) 23:21:50.83 ID:OcTVoTNp
- あとクラスもどきをクラスにするというが、
具体的に今のES仕様上に一体どのようにすれば構築するのかできるのなら説明して欲しい。
というかESへのクラスベースの導入なんてもはや100％不可能なことと考えて欲しい。
そこら辺はあくまでプロトタイプベースを活かしてどう糖衣構文を入れていくかという話しか絶対にありえない。
いくらそこがそもそも気に食わないと言ってももはやどうしようもない。
JSは歳の割にかなり拡張性と将来性を残している言語だが、
もうそこの部分は良かれ悪かれどうこうしようがないことなので完全に受け入れた上で、アイディアを出して欲しい。
今Googleが提案しているような、ES内に別モード（実質別言語）を持ち込むというような話でならいくらでも可能だ。
逆に言うとそこを変えてしまうと、もはやESではないということだ。
他にも、この仕様こそがESであり、それが仮に悪いものであっても単純にそうでなくすとESでなくなるよねということは多くある。
皆はそうしたデリケートな観念を共有して、あくまでESをESのまま良くしていこうとしているわけだ。
そこにズカズカと、好きな仕様をどうにでも定められるだろうというようなスタンスで来られると困惑する。
- 786 ：デフォルトの名無しさん：2015/07/26(日) 23:33:14.50 ID:2AM3JEIE
- 困惑するぐらいなら相手にすんなよ
- 787 ：デフォルトの名無しさん：2015/07/26(日) 23:54:12.35 ID:Z524xBvX
- ID:nH18/T+5 ID:CUGdI6EM は指摘されるたびに意見を変えて反論するから相手するだけ無駄かと
特に>>747は相当に酷かった
仕様を浅く読んで理解したつもりになって ES6 に文句をつけるから整合性にかける暴論を出すことになる
- 788 ：デフォルトの名無しさん：2015/08/02(日) 22:34:29.77 ID:jh0a8aiR
- > 213 自分：Name_Not_Found[sage] 投稿日：2015/08/02(日) 21:01:53.35 ID:???
> ちなみにここやRubyスレとかでも思うのだが、
> ローレベルコードを絶対に書かないという宗教みたいなのがあるのか？
>
> 215 自分：Name_Not_Found[sage] 投稿日：2015/08/02(日) 21:24:37.63 ID:???
> ローレベルコード： for文を使ってしこしこ
> ミドルレベルコード： map()を使う
>
> ググッたら出てきたこれがローレベルコード
> > var n = arr.length;
> > for(var i = n - 1; i > 0; i--) {
> > var j = Math.floor(Math.random() * (i + 1));
> > var tmp = arr[i];
> > arr[i] = arr[j];
> > arr[j] = tmp;
> > }
> > http://pandanoir.seesaa.net/article/341955064.html
>
> 207もそうだが、無理にミドルレベルでやろうとするから余計におかしくなる。
> トンデモコードが出てくるのはこのケースが多い。
213と215は俺。
同じこと感じている人とか、何か思うところがある人居ますか？
IDが出ない為、アホを無視しづらいのでこちらに避難してきました。
(これまでどおりアホはガン無視で行きます)
- 789 ：デフォルトの名無しさん：2015/08/02(日) 22:37:36.70 ID:j05l/s8s
- >>788
お前が馬鹿だと思う。
の一言しか無いねｗ
- 790 ： ◆wvUfy0g2Fc ：2015/08/02(日) 22:39:48.69 ID:qwTmfOsM
- IDがでるから無視しやすいよね？
- 791 ： ◆wvUfy0g2Fc ：2015/08/02(日) 22:40:45.51 ID:+DM56e7O
- だがそれは本当だろうか？
- 792 ：デフォルトの名無しさん：2015/08/02(日) 22:43:36.63 ID:J00nj+M5
- IDがでてないと無視できないような奴が
ここに来たからって無視できるわけないだろうｗ
- 793 ：デフォルトの名無しさん：2015/08/02(日) 22:50:34.77 ID:ea/y5J7a
- >>788
主張には同感。
ただ、
・「ローレベル」では誤解する人もいるだろうから、ひとこと補足してやるといいかもしれない。
・君が書いたローレベルコードは一番初めに既に回答に出ている。
・宗教とかいう言葉で煽る必要はなかったのでは。自分から煽ったからにはまともな回答はないと思った方がいい
- 794 ：デフォルトの名無しさん：2015/08/02(日) 22:53:09.75 ID:ggNRziQ9
- > (これまでどおりアホはガン無視で行きます)
意訳 自分が望んだレスをした人にしか
レスをしません。俺が正しい、反対意見は受け付けない。
- 795 ：デフォルトの名無しさん：2015/08/02(日) 23:07:16.76 ID:jh0a8aiR
- >>793
「ゴミ」というのは煽りと取られても問題ないが、「宗教」は煽りか？
まあそれはさておき、とにかく宗教じみたものを感じる。
ただこれはJavaScriptだけの話ではない。
これって一通りクラスライブラリがそろっている状況で始めた人はそうなるのか？
実は結構前から疑問だった。
183についても同じだろ。substr()を使ってローレベルで書けばいいだけの話、(189)
それをなぜ別ライブラリまで持ってきてミドルレベルで処理しようとする？(185-)
何か理由があるんだと思うよ。（正当かどうかは別として）
俺はそれを聞きたいだけ。
- 796 ：デフォルトの名無しさん：2015/08/02(日) 23:37:51.83 ID:ea/y5J7a
- >>795
それについては俺は分からんから、ライブラリで答えてる人に聞いてくれｗ
ライブラリの宣伝かも知れないし、
例外処理まで考えて答えてることもあるかも知れないし、
本当にローレベルの書き方を知らんのかもしれない。
- 797 ：デフォルトの名無しさん：2015/08/02(日) 23:41:30.90 ID:jh0a8aiR
- ちなみにRubyは一部そういう思想があって、
これはMatz自身が公演で言っていた記事（スライド付き）があったはずだが出てこない。
今見つけたのは、
> for (i=0; i<100; i++) {
> ...
> }
>
> 100.times do
> ...
> end
>
> http://sssslide.com/www.slideshare.net/yukihiro_matz/ruby-9183142 (P22)
これをRubyでは「100回繰り返すのならただそう書ければいい。
for文を使って記述するのは実装が染み出ているから俺は嫌だ！」
（PCの構造に合わせた記述ではなく、人間的記述をしたい）
といった感じだったはず。
だから配列の添字を見る必要が無ければ基本的にeachを使えとか。
俺はこの思想はありだとは思う。
ただ、今やっている奴も、また他の奴らもこれとは違う。
だから何か別の考えがあるのかなと思ってね。
- 798 ：デフォルトの名無しさん：2015/08/03(月) 00:01:38.53 ID:cWVJEpaZ
- 「ローレベルコード」はプログラミングにおける専門用語として確立されているんだろうか
低級言語ならわかるが、ローレベルコードは調べてもMRP用語集しか出てこなかった
JavaScriptライブラリが高級言語とすれば、ECMAScriptが低級言語とするのはまあわかる
が、for文が Array#map と比較して低級なのは納得いかない
Syntax 上で見ても Array#map の構成要素に IterationStatement は存在しない
…と思うのだが、俺の理解が間違っているだけなんかね
- 799 ：デフォルトの名無しさん：2015/08/03(月) 00:09:57.51 ID:m4wBjZ5s
- ローレベルなコードって、ハードウェアを直接扱うなどの機械に近い部分を指して使う言葉だと思っていたのだが
JS書きの人だと違う扱いなん？
- 800 ：デフォルトの名無しさん：2015/08/03(月) 00:12:52.00 ID:LVtpEOkX
- 聞いたことないですオレオレ造語かと
- 801 ：798：2015/08/03(月) 00:25:08.93 ID:cWVJEpaZ
- 「ローレベルプログラミング言語(low-level programming language) = 低水準言語(低級言語)」ならあるんだよな
俺の理解では「ECMAScript = 高級言語」「機械語 = 低級言語」だが
ローレベルコードはMRP用語では「最小の部品」を示すらしい
その定義に則るなら jQuery に対して ECMAScript, DOM ...etc がローレベルコードとするとしっくりくるので、>>798では適当に解釈した
まあ、俺も造語だと思ってるけど、どこから定義を引っ張ってきたのかは興味があるな
- 802 ：デフォルトの名無しさん：2015/08/03(月) 04:34:09.92 ID:ItltWBnz
- 何をそんなに憤ってるのか全くよく分からん。
ただ処理の流れが分かりやすくコードが見やすくなるように、
説明としてforの代わりにmapを使ったりすることはよくあるだろう。
特に今回はアルゴリズムの話をしているのだからmapかforかは全くどうでもいいことだろう。
- 803 ：デフォルトの名無しさん：2015/08/03(月) 11:14:35.50 ID:64VH5b8t
- 788 の場合に限って言えば、そんなに情報量が少ないのに長いコードはうんこだろ。
それに停止性問題では状態があるから NP 困難って話なんだから、本質的に必要ないのに変数を増やすのはバカだ。
- 804 ：デフォルトの名無しさん：2015/08/03(月) 12:28:04.96 ID:cWVJEpaZ
- 辞書にも載ってない「ローレベルコード」の定義が一人歩きしてるから厳密に定義しろ、ってことだろ
for文は速度において優位性があるので使うことがあるが、「ローレベル」という言葉を使うなら for 文も Array#map と等価コードを書け、とは思うね
Web制作板のライブラリ推奨者は前に「布教のため」といっていたからそういうことなんだろう
id強制表示する板に移動するのは対策としては有効だが、どこに移るかが問題だな
- 805 ：デフォルトの名無しさん：2015/08/03(月) 20:16:12.49 ID:OzQ4PZKS
- 好きな所に行けばいいんじゃね？
いちいち他人に許可もらわなくていいんだよ？
移動するぞ？ 本当に移動するぞ。
いいんだな？ （チラッ）みたいな
言い方しなくていいんだよ？
どうせ俺にとっては巡回先が増える程度のことでしか無いし。
- 806 ：デフォルトの名無しさん：2015/08/03(月) 20:44:50.67 ID:AaPz/OI2
- >>803
君が質問スレ207の作者か？
そして君の価値観では、うんこコードとは、
・長い
・変数が多い
ということでいいか？
ちなみにどこで習った？
あるいはどこの文化？出身言語は？
悪いが俺は質問スレ207のコードはゴミだと断定できるから、認めて君ならあきらめろ。
もちろん君が俺のコードをうんこだというのも自由だ。その上での意見交換だけにとどまる。
（厳密には俺製ではなく引用だが、俺も同質のコードを書く）
- 807 ：デフォルトの名無しさん：2015/08/03(月) 20:46:47.27 ID:Po35HDPO
- > ちなみにどこで習った？
MIT
> あるいはどこの文化？出身言語は？
リーナスと同じ
- 808 ：デフォルトの名無しさん：2015/08/03(月) 21:45:55.00 ID:5H1wWT1h
- >>806
自分（≠>>803）が質問スレ207の作者ですぞ
正直ネタで書いたウンコ以下のコードが元でここまで荒れてしまって申し訳ないですぞ
- 809 ：デフォルトの名無しさん：2015/08/03(月) 21:54:33.07 ID:5H1wWT1h
- 元スレでも謝りたいけれど怖くてやっぱりずっと書き込めないのですぞ
どなたか代理をおねがいしまする
- 810 ：デフォルトの名無しさん：2015/08/03(月) 22:14:14.76 ID:AaPz/OI2
- >>808
いや、ネタならネタでいいんだが、
問題はこの界隈にはそれを分からない奴も多いってことだ。
言葉に妙に引っかかっている奴がいるが、はっきり言えば言葉なんて通じればいいだけのもの。
何と聞かれてこうと示したらそれでよし、それ以上突っかかってくること自体がおかしい。
（対話ではなく、突っかかることが目的になっている。
俺はローカル方言だとは思ってないけど、そのこと自体はどっちでもいい。)
話を聞く限り、どうやらこいつらは抽象度を気にしたことが無いらしい。
確かにJavaScriptの抽象度は比較的一定だから、気にすることが無いのかもしれない。
ただそのネタとは別に、ミドルレベルのコードで無理にやろうとしている奴がJavaScript以外でも散見される。
だから何か理由があるのだと思う。知ってたら教えて欲しい。
- 811 ：デフォルトの名無しさん：2015/08/03(月) 23:30:26.08 ID:LVtpEOkX
- 気持ち悪い
- 812 ：デフォルトの名無しさん：2015/08/03(月) 23:41:12.58 ID:Ov65K202
- >>810
抽象化が好きだろうが嫌いだろうがそれは個人の好みだからどうでもいいわな。
forだろうがforEachだろうが未知の模擬コードであろうがどうでもいい。
高速なコードを書いてくれと言われてるのではないのだから、
それは読む人が心のなかで置き換えればいいこと。
- 813 ：デフォルトの名無しさん：2015/08/04(火) 04:45:38.78 ID:RQvOsE8M
- >>809
> 元スレでも謝りたいけれど怖くてやっぱりずっと書き込めないのですぞ
気にする必要ない。
どうせ何も手出しできないんだから。
あんたが本人なら、見ててわかるだろう？
誰が誰だとか、適当な事ばかり言ってる。
結局のところ、"あいつ" はスレが自分の
思うとおりにならんのが気に食わなくて暴れてるだけ。
自分が嵐になってることに気づいていない。
- 814 ：デフォルトの名無しさん：2015/08/04(火) 09:49:15.20 ID:aYo6Ibo6
- いや気が付いてるって……
奴は忘れかけた頃にいつもやって来るlodash厨で荒らしの常連
- 815 ：デフォルトの名無しさん：2015/08/04(火) 10:24:06.96 ID:Wrx2TKJj
- >>810
あんたのいうミドルレベルかローレベルかはどうでもいい
ミドルレベルだろうが、ちゃんとしたコードなら問題ない
「ミドルレベル＝無理にやろうとしている」のレッテルを貼ることがおかしい
- 816 ：デフォルトの名無しさん：2015/08/04(火) 14:33:08.18 ID:IBYPbZ5X
- >>806
読解力が極端に低いか、負けを認めるまで負けない式の発言か、どちらかだな。
「長いのに情報量が少なくて、本質的に必要でない変数がある」コードがうんことは限らないって主張している
ということでいいか？
ちなみにどこで習った？
あるいはどこの文化？出身言語は？
- 817 ：デフォルトの名無しさん：2015/08/04(火) 19:09:26.17 ID:RntsE6hp
- 話を戻すと質問スレ207の何がミドルなんだろうか
シャッフルに乱数列を用いるという考え方自体なのか
cryptoAPIを使うことなのか
それともmapを使っていることなのか
- 818 ：デフォルトの名無しさん：2015/08/04(火) 19:14:42.91 ID:jrX1aju4
- 207ってどんなコードなん？
- 819 ：デフォルトの名無しさん：2015/08/04(火) 19:35:41.38 ID:4xPxleWj
- var shuffle = ary => {
var len = ary.length
do { var ra = [...new Set(crypto.getRandomValues(new Uint32Array(len)))] } while ( ra.length !== len )
return [...ra].sort().map( (v, i) => ary[ra.indexOf(v)] )
}
- 820 ：デフォルトの名無しさん：2015/08/04(火) 19:47:22.44 ID:4xPxleWj
- もう一つ話題になってるのを>>819で書くとこうか
var shuffle = ary => {
ary = [...ary]
for (var i = ary.length - 1; i > 0; i--) {
var j = (Math.random() * (i + 1)) | 0
;[ary[i], ary[j]] = [ary[i], ary[j]]
}
return ary
}
- 821 ：デフォルトの名無しさん：2015/08/04(火) 21:00:53.74 ID:ATMQZhAh
- >>819-820
?
元スレで既出かもだが、乱数列に対応付けて並べ替えるなら207はこれでいいような
let shuffle = ary => ary.map(v => ({v, r: Math.random()})).sort((l, r) => l.r - r.r).map(e => e.v)
最初のmapは関数型言語だとzipを使うんだろうな
それよりarrowやらspreadやら使ってるのにvar使ってるのが気になるw
- 822 ：デフォルトの名無しさん：2015/08/04(火) 21:03:54.24 ID:LaebqzUe
- >>821
だから、俺こんなの知ってるんだぜーみたいな
臭がするって話さ。
- 823 ：810：2015/08/04(火) 21:43:44.51 ID:ItemCqqU
- >>821
ちなみに言っておくと、質問スレ207=819でSetが使われているのは、sortが「安全なソート」だからだ。
だから厳密に言えばSetを外すのは間違い。
808はそこまで知っていて書いているので、ある意味「ネタ」だという証明になっている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
- 824 ：デフォルトの名無しさん：2015/08/04(火) 22:07:58.23 ID:2w4CQfTI
- ここは ES スレであって「JavaScriptスレになぜこんな奴がいるんだ？」の疑問を解消するスレではない事をわかってない奴が約一名いるようだが
- 825 ：デフォルトの名無しさん：2015/08/04(火) 22:17:53.13 ID:ATMQZhAh
- >>823
sortは「安全なソート」"かもしれない"、だよね
多くは安定らしいけど、Chromeで大きなサイズのsortは安定じゃない
でも正直そこは考えてなかったわ
あと、>>819は最後にindexOf使ってるから不安定なソートが保証されてもSetが必要では？
元の配列が[1,2]で(Set抜きで)乱数列がたまたま[0,0]になった場合、シャッフル後の結果は[1,1]になるのでは
- 826 ：デフォルトの名無しさん：2015/08/04(火) 22:37:59.36 ID:aBky5kbq
- >>825の言う通りでsortの安定性関係なくSetと長さチェックは必要
- 827 ：デフォルトの名無しさん：2015/08/04(火) 22:39:43.21 ID:ItemCqqU
- >>825
> あと、>>819は最後にindexOf使ってるから不安定なソートが保証されてもSetが必要では？
ああ、これはその通りだ。
こちらは前のSetでuniqが保証されていたので、それ以降はuniqだとして読んでいたので見落とした。
808がSet使った理由はこっちかも。
> 多くは安定らしいけど、Chromeで大きなサイズのsortは安定じゃない
てかこれ大問題だろ！勝手に仕様変えてんじゃねえ！
Quiitaではなんか突っ込まれまくっていて既に原文が差し替えられているので当時の状況は分からないが、
「崩壊」「罠」「鬼畜」という表現で正しいと思うのだが。(少なくともプログラム書く側からしたら感情的にはこれ）
http://qiita.com/falsandtru/items/41591040633bc88fcde7
http://wakuworks.jugem.jp/?eid=169
- 828 ：デフォルトの名無しさん：2015/08/04(火) 22:48:34.76 ID:GXXil41H
- 仕様は変わってないよ
ECMAScript 1の頃からソートが安定である必要はないとかかれてる
- 829 ：デフォルトの名無しさん：2015/08/04(火) 22:48:54.44 ID:aBky5kbq
- 貴方は本当にJSerですか？
ESのsort仕様に安定性の規定はなく安定でなくても良いのは有名です
- 830 ：デフォルトの名無しさん：2015/08/04(火) 22:52:48.47 ID:aBky5kbq
- 何度もESコミュでも挙がってるし、未だにV8のissueでも挙がるけれど、
結論としてはそもそもsortというものは、
どんなアルゴリズムがベストかは対象によって様々であり、
オールマイティなアルゴリズムがどうであるべきかを決められるものでもない
期待するアルゴリズムがあるのならば自分で作るべきだということ。
- 831 ：デフォルトの名無しさん：2015/08/04(火) 23:17:53.46 ID:ItemCqqU
- >>829
それでお前は何者なの？
明らかにプログラマじゃないよね。
> 92 返信：デフォルトの名無しさん[sage] 投稿日：2015/08/04(火) 22:47:29.22 ID:aBky5kbq
> >>88
> 別にJS自体にはスレッドの規定はないし、そういうアーキテクチャでもない。
> マルチスレッドなぞ外から付け加えれば済むようなもの。
> http://peace.2ch.net/test/read.cgi/tech/1438094104/92
前から思ってるんだけど、JavaScriptスレはエセプログラマも多すぎる。
- 832 ：デフォルトの名無しさん：2015/08/04(火) 23:30:29.35 ID:aBky5kbq
- 私はしがないJSerです。
それ以上でも以下でもありません。
- 833 ：デフォルトの名無しさん：2015/08/04(火) 23:41:09.00 ID:2w4CQfTI
- 仕様の話をしていると仮定して、ES 仕様にはスレッドの概念などないから何も間違ってはいない
- 834 ：デフォルトの名無しさん：2015/08/04(火) 23:41:42.41 ID:ATMQZhAh
- ん？ 引用されてるマルチスレッドの話がエセ呼ばわりされてるのか？
実際ESには処理モデルの規定はなかったんじゃ？
(ES6にはJobsとJob Queuesが入ったので今でもないと言えるかわからんが)
少なくともRhinoはマルチスレッドをサポートしてるよね
- 835 ：デフォルトの名無しさん：2015/08/04(火) 23:54:00.59 ID:x8+Suvq5
- まあ変な話エンジンが勝手にマルチスレッドで動くようにしても
仕様違反じゃないし仕様の概念とも衝突しないだろう
（>>834の言うようにJob Queueはかするかもしれないが）
そういう面ではやはり「JavaScriptはシングルスレッドアーキテクチャ」とは言えないだろうな
- 836 ：デフォルトの名無しさん：2015/08/05(水) 00:43:41.34 ID:zRxTkvOd
- >>832
>>835
JavaScriptスレで奇妙に感じるのは、
お前らの「仕様の知識」と「プログラミングの腕前」があまりにも乖離している点だ。
君らのことだよ。お前らは一体何者なんだ？
満足できる回答があれば、831の何が間違っているか回答しよう。
質問スレの話だと、53は俺だ。
45を見て、「このコードを自分で書ける奴がする質問ではない」とすぐに分かった。
つまり、45はどこかからのコピペだ。
それを46も感じているからあの回答になっている。
そしてlodash厨はこれが分からない＝プログラマではないというのも判明した。
くだらない争いをしているので53で援護射撃した。
しかし大半はこの流れを理解できているようでもない。
これまでもそうだが、「仕様」については異様にこだわるのに、
コードについてのこだわりがほとんど無いのは、かなり奇異だ。
一人や二人ではない。お前らは一体何者なんだ？
他プログラミング言語スレと大幅に雰囲気が異なるのは、お前らのせいだと思っている。
ちなみに>>834(ID:ATMQZhAh)はプログラマだ。（職業か日曜かはさておき）
「仕様の知識」と「プログラミングの腕前」≒「コードへのこだわり」が釣り合っている。
- 837 ：デフォルトの名無しさん：2015/08/05(水) 00:48:57.72 ID:KiyThsAq
- webworkerが入った時点でマルチスレッドだろJK
- 838 ：デフォルトの名無しさん：2015/08/05(水) 02:24:11.67 ID:u2uaH0Xe
- >>837
それESの範囲じゃないですしおすし
- 839 ：デフォルトの名無しさん：2015/08/05(水) 05:54:16.44 ID:HdJkl2eK
- >>836
lodash厨は俺なんだが、
この話題に俺は参加してないぞ？
なんで勝手に俺だと決めつける？
- 840 ：デフォルトの名無しさん：2015/08/05(水) 10:56:15.94 ID:A+1+0YPe
- >>836
ここは仕様の話をする場なんだよ
JavaScriptスレ住民の知識の多寡について議論する場ではない
lodash房はどう見ても仕様に詳しくないだろ(仕様もプログラミングの腕前もたいした事はない)
いい加減、スレ違いだから出て行け
- 841 ：デフォルトの名無しさん：2015/08/05(水) 15:15:11.77 ID:3/pHYZqO
- よく分からん。
仮にESやJSにいろんなマルチスレッド性（Parallels、ESWorker、SAB、Atomic）が入っても性質が大きく変わったとは思わないし、
例えばWebやNodeでのプログラミングが大きく変化するとは思えない。
CompositorWorkerみたいなのは重要でWebプログラミングを大きく変える可能性もあるが、少なくともESとは関係ない。
皆はそういうごく自然なことを言ってるだけでただ>>836がES/JSの仕様、歴史、文化に詳しくなくて感覚がずれているだけと思うが、
もう少しだけ付き合うと
>>「仕様」については異様にこだわるのに、コードについてのこだわりがほとんど無い
とは具体的にどういうレスを指して言っているの？
>>836の主張は抽象的でチラ裏に近い。もっと具体的に主張してくれないと反応に迷う。そうでないのならこれ以上は荒らしになる。
- 842 ：デフォルトの名無しさん：2015/08/05(水) 19:59:33.67 ID:HdJkl2eK
- 自治しているつもりで、
誰はダメ、これもダメ。
なぜなら俺が気に食わないから
という荒らしが多いからなｗ
- 843 ：デフォルトの名無しさん：2015/08/06(木) 13:40:20.80 ID:y/VksE8c
- > このスレでは、★言語★としてのECMAScript(JavaScript、JScript等)の話題を扱います。
> ブラウザ環境でのJavaScriptはWeb製作板へ。ASP、CGIなどはWebProg板へ。
こうテンプレにあるのに、JavaScript どころか JavaScript スレの話をして敵意を撒き散らしているんだから、元々荒らしでしかないだろう。
- 844 ：デフォルトの名無しさん：2015/08/06(木) 14:45:09.94 ID:JcwAodaR
- まあJSerもしくはこのスレ住民の文化常識を知りたいってことであれば
ぎりぎりセーフなのかなと思ったけど
- 845 ：デフォルトの名無しさん：2015/08/06(木) 15:23:02.00 ID:AT8V+Th4
- はい、おわりおわり
- 846 ：デフォルトの名無しさん：2015/08/15(土) 19:19:23.77 ID:+dJSDeN5
- ES2015が去年のこの段階でDraftが20超えていたことと、
それでも次年に持ち越したことを考えるとES2016は無理そうじゃないか？
それともたった２，３機能の追加になるとしても意地でも毎年リリースするのかな？
- 847 ：デフォルトの名無しさん：2015/08/15(土) 20:15:53.37 ID:AJ78Rk2y
- もうliving standardでいいじゃない
- 848 ：デフォルトの名無しさん：2015/08/17(月) 20:59:41.53 ID:4nKJpfc6
- 問題はWebAPIsと違って機能同士が排他的であることが少ないことだね。
Array.prototype.includesみたいのなら、それだけを見て入れることができるけど。
- 849 ：デフォルトの名無しさん：2015/09/17(木) 09:27:54.61 ID:KW01biK2
- まあincludesも厳密にはString.prototype.includesとの兼ね合いがあったりもする
- 850 ：デフォルトの名無しさん：2015/09/25(金) 22:03:51.94 ID:O2z7EToD
- どの辺までが次のversionに入るのかなあ
https://github.com/tc39/ecma262
- 851 ：デフォルトの名無しさん：2015/09/26(土) 08:24:45.42 ID:6zQ9hqBE
- コンストラクタ又はclassにおける private property 的なものは ES7 で出来ないだろうか。
WeakMap で疑似的に実装可能なのはわかるが、スマートな手段が欲しい。
- 852 ：デフォルトの名無しさん：2015/10/01(木) 22:48:37.44 ID:q/VNGVtY
- stage 0にregexp look behindが入ってるなあ
採用されたら地味に嬉しい
- 853 ：デフォルトの名無しさん：2015/10/03(土) 21:05:54.92 ID:R+sy4V45
- ECMA-262のエディタ交代ですか
- 854 ：デフォルトの名無しさん：2015/10/07(水) 20:03:31.91 ID:zkPtHu2v
- 今一番大きな動きとしてはAsync FunctionsがStage 3になって実装推奨フェーズに入ったってことか。
Mozillaは早速実装が始まったし、Eageは元から積極的だし、
こりゃ年内にはモジュール周りより先にモダンブラウザに実装されるかもな。
- 855 ：デフォルトの名無しさん：2015/10/08(木) 22:10:09.55 ID:BhHV9Dom
- なんでモジュールなかなか実装されないん？
- 856 ：デフォルトの名無しさん：2015/10/08(木) 22:27:52.42 ID:adZ4aRgn
- JSエンジンだけで済まないからじゃね
- 857 ：デフォルトの名無しさん：2015/10/09(金) 02:24:10.76 ID:SzdB9i+3
- >>855
ES仕様はシンタックスだけで、具体的な動作やAPIはWHATWGに分離されたから。
http://whatwg.github.io/loader/
シップされてフラグが外れるまでもう丸１年はかかるだろう。つまり実質ES7と同じだ。
- 858 ：デフォルトの名無しさん：2015/10/11(日) 17:19:46.67 ID:Lev/+Gxl
- do expression来たね
https://chromiumcodereview.appspot.com/1399893002/
これで
fn = a => { console.log(a); return b(a) }
みたいなのが
fn = a => do{ console.log(a); b(a) }
と書けるね！
- 859 ：デフォルトの名無しさん：2015/10/11(日) 17:21:17.94 ID:ngi+Bnfd
- あんま嬉しくないな
- 860 ：デフォルトの名無しさん：2015/10/11(日) 17:27:25.07 ID:/RfOwZOP
- 面白いけど既存の構文と似てるけど微妙に違う動作ってうっかりはまりそうでやだな
- 861 ：デフォルトの名無しさん：2015/10/11(日) 18:30:26.36 ID:Lev/+Gxl
- 使い所としては
const hoge
if (〜〜〜) {hoge = 1} else {hoge = 2}
はエラーまたは無視になるけど
const hoge = do {
if (〜〜〜) {1} else {2}
}
のように書けたりできる
- 862 ：デフォルトの名無しさん：2015/10/11(日) 19:35:47.88 ID:/RfOwZOP
- 軽量即時関数的に使うものなの？
- 863 ：デフォルトの名無しさん：2015/10/11(日) 19:38:51.67 ID:6jGim2k9
- そうだね
- 864 ：デフォルトの名無しさん：2015/10/12(月) 00:09:12.72 ID:B6Kw8hTn
- >>861
三項演算子の方がスマートだな
const hoge = (~) ? 1 : 2;
- 865 ：デフォルトの名無しさん：2015/10/12(月) 00:15:43.65 ID:jHkNiRsm
- 文のブロックを式として扱えるなら、for-ofとかも使えて条件演算子でできないことも可能になるけどな
- 866 ：デフォルトの名無しさん：2015/10/12(月) 00:26:40.19 ID:B6Kw8hTn
- 三項演算子の場合、カンマ演算子を使えば可能性が広がると思うが
- 867 ：デフォルトの名無しさん：2015/10/12(月) 00:44:59.72 ID:mTfU9bDT
- switchのcase節の中にでも埋め込むかね・・・
基本的にはそもそもブロックスコープ何個も入れるようなでかい関数作るなって話だが
- 868 ：デフォルトの名無しさん：2015/10/14(水) 20:06:39.47 ID:/8FBknfD
- list.sort(>) クルー？
https://esdiscuss.org/topic/swift-style-syntax
- 869 ：デフォルトの名無しさん：2015/10/14(水) 20:15:45.47 ID:tB4uqM6F
- 局所的にだけセクション使えてもね
- 870 ：デフォルトの名無しさん：2015/10/14(水) 20:42:09.75 ID:RZLA+pyr
- Babelを使ってES6、ES7、その後を、ES5にトランスパイル
することで古いブラウザでも動くようになる。
そうやって新しい構文を使うのが今のJavaScriptの主流です。
- 871 ：デフォルトの名無しさん：2015/10/14(水) 21:26:01.22 ID:32q5eLtw
- それは少しズレてると思う。
古いブラウザではなく、常にモダンブラウザの実装を補うためのものだと思う。
だっていくら新しい構文が使えても新しいAPIが使えないと仕方がないもの。
例えばPromiseを返すWebAPIが無いような環境だとasyncの使い道は半減する。
- 872 ：デフォルトの名無しさん：2015/10/15(木) 04:20:12.64 ID:kMs2XARu
- > 古いブラウザではなく、常にモダンブラウザの実装を補うためのものだと思う。
同じ意味では？
同じモダンブラウザでも、新しいバージョンが出れば古くなる。
IE9世代であってもモダンブラウザって言われていたんだしね。
> 例えばPromiseを返すWebAPIが無いような環境だとasyncの使い道は半減する。
それはPolyfillライブラリの話であって、Babel（ECMAScriptという言語が対象）の話じゃないよ。
- 873 ：デフォルトの名無しさん：2015/10/15(木) 04:23:17.89 ID:8y87T4ny
- 見た感じ>>870は聞きかじったことを書いただけって感じだから掘り下げるほどのことでもない
- 874 ：デフォルトの名無しさん：2015/10/15(木) 04:44:58.55 ID:kMs2XARu
- >>870=872だけどねｗｗｗ
- 875 ：デフォルトの名無しさん：2015/10/15(木) 05:55:51.01 ID:1ZzLazOW
- いくらポリフィルがあると言っても例えばFetchは完全エミュ不可だし
最低限必要なレベルでもBlobのサポートがいるからIE9は対象外になる。
それからES6の範囲で言ってもまずシンボル系のいくつかはトランスレータでの対応が困難だし
Proxyに至っては不可能と言っていいレベルだ。
ビルトインコンストラクタのサブクラスというES6のメインの機能も
最低限プロトタイプの書き換えが出来ないと再現できないから、IEだと11のみになってしまう。
当然ES7の範囲だともっと多くの対応困難な機能がある。
それらを考えると結局いくらES5に変換してくれると言っても
実際はこれでES5に対応しているブラウザに対して未来永劫新しい機能を使っていけるという
夢のツールではないことは分かる。
- 876 ：デフォルトの名無しさん：2015/10/15(木) 06:11:10.13 ID:1ZzLazOW
- >>872
>同じ意味では？
同じ意味ではないでしょ。
まあ来年にはIEも11くらいしかサポート要らなくなるし、意味が近づいてきてるのは確かだけど
あくまできちんと先端を追いかけ続けて更新されるブラウザ＝＞モダンブラウザにおいて
そのもうちょっと先までを使えるようにするのが現実という意味でしょうよ。
- 877 ：デフォルトの名無しさん：2015/10/15(木) 06:29:48.61 ID:8y87T4ny
- Nodeはともかくブラウザだとポリフィルのコードサイズが結構な負担になるから
トランスパイルできるならなんでも使っていいというものですらない
コーディングスタイルのためにペイできるコストではないし
Babelはコードをクロスブラウザ対応に変換してくれる魔法のツールではない
API対応のチェックは今までどおり必要になる
- 878 ：デフォルトの名無しさん：2015/10/15(木) 08:46:09.74 ID:HeeGmQmp
- >>876
モダンブラウザの定義がおかしいのでは？
モダンブラウザっていうのはウェブ標準に十分準拠してるってことで
その反対は準拠していないということ。つまりバグがない。
新しい機能をサポートしていることじゃないんだよ。
一旦モダンブラウザと呼ばれたら、そのブラウザ以降は
永遠にモダンブラウザだよ。
- 879 ：デフォルトの名無しさん：2015/10/15(木) 08:47:30.35 ID:HeeGmQmp
- >>877
> Babelはコードをクロスブラウザ対応に変換してくれる魔法のツールではない
> API対応のチェックは今までどおり必要になる
当たり前じゃね？ BabelはJavaScript（EcmaScript）を対象とするもので、
ブラウザが搭載するAPIを補完するものじゃないもの。
APIを保管するのはBabelではなくてポリフィルの役目。
- 880 ：デフォルトの名無しさん：2015/10/15(木) 08:50:47.88 ID:HeeGmQmp
- ブラウザが提供するAPI＝JavaScriptのAPIと勘違いしている人かなぁ。
大雑把な説明をすれば、ブラウザにもNodeにも両方にあるものが
JavaScriptの部分であり、Babelが対応する部分だよ。
NodeでBabelは使えるが、そのBabelがNodeでブラウザ用APIの
ポリフィルを実装するわけないしｗ
大概のブラウザ用APIはBabelの対象範囲ではない。
- 881 ：デフォルトの名無しさん：2015/10/15(木) 09:10:25.49 ID:8y87T4ny
- だから違うと言ってるのに何でこのひと一人で勘違いして舞い上がってんの
- 882 ：デフォルトの名無しさん：2015/10/15(木) 09:37:25.55 ID:HeeGmQmp
- ん？ 俺は最初からBabelはJavaScriptを古いブラウザでも動かすものと言ってるだけ。
ブラウザのAPIの話なんかしてないし、ポリフィルを提供するものとも言ってない。
JavaScriptオンリー、ECMAScriptで決められた仕様の範囲の話しかしてないよ。
（WebAPIはECMAScriptの対象外）
- 883 ：デフォルトの名無しさん：2015/10/15(木) 13:38:06.98 ID:+IYnNee8
- Web制作板にいた人と同じ匂いがする。
いい加減にBabel推奨して少し矛盾点をつつかれると「当然だろ」と後出しで言い返すあたりがそっくり。
- 884 ：デフォルトの名無しさん：2015/10/15(木) 13:58:13.48 ID:N9hEQVX6
- >>882
違うって言っておけばいいのか？
そんなどうでもいいことより、内容に対してレスすればいいのに
- 885 ：デフォルトの名無しさん：2015/10/15(木) 14:56:15.23 ID:9WLmak9d
- 同じ匂いも糞も引用や単芝の使い方全く同じだから同一でしょ
- 886 ：デフォルトの名無しさん：2015/10/15(木) 19:33:06.01 ID:N9hEQVX6
- 頭悪すぎるｗ
- 887 ：デフォルトの名無しさん：2015/10/15(木) 20:01:17.80 ID:2/AXfKBA
- こんなのが二人もいたら嫌すぎるな
- 888 ：デフォルトの名無しさん：2015/10/15(木) 23:37:17.22 ID:mn0BrUjG
- >>882
ブラウザの話だと認めつつもWeb APIを除くとは矛盾してるだろ
そもそもスクリプト言語、特にIOと切り離されたJSってのは
逆に何かを実現するには外様APIありきで、それらを切り離して考えることはできない。
- 889 ：デフォルトの名無しさん：2015/10/15(木) 23:40:58.91 ID:mn0BrUjG
- >>878
今のWeb標準の多くがLSだから、当然自動更新でないブラウザは準拠してるとは言えないし
モダンブラウザとは言えないんじゃないか？
- 890 ：デフォルトの名無しさん：2015/10/15(木) 23:51:41.66 ID:XerH+8kv
- >>888
> ブラウザの話だと認めつつもWeb APIを除くとは矛盾してるだろ
ブラウザでJavaScriptを動かすという話をした。
Nodeで動かすという話はしていないが、
Nodeの話ではないということではなく、単にしなかっただけ。
ブラウザでJavaScriptを動かすという話をしたが、
それがWeb APIと何の関係があるんだ？
- 891 ：デフォルトの名無しさん：2015/10/16(金) 08:46:34.12 ID:Wb9pxNM+
- それは現実を見ていないキレイ事ですらない殆ど意味を持たない戯言だろうよ。
いつまでも赤子のように駄々をこねないでいい加減分かった方がいい。
- 892 ：デフォルトの名無しさん：2015/10/16(金) 09:14:17.14 ID:ZoTRSHay
- またなんか意味不明なこと言い出してるなｗ
- 893 ：デフォルトの名無しさん：2015/10/16(金) 09:33:54.69 ID:bmsNGfoJ
- あー、ただ意地はってるだけかと思ってたが、本当はおつむが足りてないのか。
すまなかったな。
- 894 ：デフォルトの名無しさん：2015/10/16(金) 17:28:25.18 ID:JdE1CG/Y
- Web APIってRESTfulとかのあれのイメージ
上ではDOM/BOMその他のAPIがWeb APIって呼ばれてるようで？？？ってなった
- 895 ：デフォルトの名無しさん：2015/10/16(金) 19:01:40.74 ID:lf5L1wBF
- それでいきなりNodeが出てきたり話が噛み合ってなかったのね
主にW3CやMozillaが好んで使ってる言い回しみたいだね
http://www.w3.org/2006/webapi/
https://developer.mozilla.org/ja/docs/Web/Reference/API
http://www.w3.org/standards/webdesign/script
- 896 ：デフォルトの名無しさん：2015/10/16(金) 19:53:29.17 ID:Knm5EuzE
- ことの始まりは>>870なんだから>>870だけ叩けばそれで終わりなのを無駄に話広げすぎ
- 897 ：デフォルトの名無しさん：2015/10/16(金) 20:13:17.93 ID:ElInVZjL
- >>895
w3cの方は2008年にはWebAppsに変わってるな
Ajaxが広まって紛らわしくなったのがその時期かな
- 898 ：デフォルトの名無しさん：2015/10/16(金) 20:56:45.22 ID:01CLZvjm
- >>871は割とまともな意見だと思うが、何が琴線に触れたんだろう
- 899 ：デフォルトの名無しさん：2015/10/16(金) 21:16:17.35 ID:Knm5EuzE
- BabelやTSを使えるときは使って生産性を上げる、それだけのこと
- 900 ：デフォルトの名無しさん：2015/10/16(金) 21:36:54.99 ID:ZoTRSHay
- >>870もまともな意見でしょ？
JavaScriptの新しい構文を使うとしか言ってない。
- 901 ：デフォルトの名無しさん：2015/10/16(金) 21:39:38.74 ID:kIfY2weg
- 最近typed objectsやvalue objectsの話題がないので寂しい
- 902 ：デフォルトの名無しさん：2015/10/17(土) 08:17:36.09 ID:rFd7029s
- >>870はES5にトランスコンパイル不可能な機能は未来永劫使うな、といっているのでまともなわけがない
- 903 ：デフォルトの名無しさん：2015/10/17(土) 08:22:01.79 ID:KBdUYWvy
- > ES5にトランスコンパイル不可能な機能は未来永劫使うな、といっているので
言ってないだろ？
- 904 ：デフォルトの名無しさん：2015/10/17(土) 12:26:05.39 ID:LPkcFD91
- ES5 にトランスコンパイルするということは ES5 で実装可能な範囲だけのコードにする事と同義だから例えば、Proxy は使用出来ない
- 905 ：デフォルトの名無しさん：2015/10/17(土) 17:33:53.33 ID:arnD15ON
- 個人的に実運用上気になるのはパフォーマンスだね
例えばasync関数はES7非対応環境にはジェネレータと補助関数でシミュレートするだけでいいが、
ES6非対応環境にはジェネレータをtry-catchとswitch文でシミュレートする他、Promiseもシミュレートしなければならない。
おまけにエンジンも古いわけだから、パフォーマンス上で同等な使い勝手にならないんじゃないかと思ってる。
- 906 ：デフォルトの名無しさん：2015/10/17(土) 18:21:31.14 ID:/J6P+2iK
- パフォーマンスの検証がこの前Qiitaに上がってたけどほぼ互角みたいよ
コードサイズの増加が半端無くて使う気なくしたけど
TSも対応するらしいけど出力の可読性のポリシーと合わないんじゃないかな
- 907 ：デフォルトの名無しさん：2015/10/17(土) 19:20:57.74 ID:pib/Nfzj
- >>906
コードサイズはどうせgzip圧縮するんだから、さほど増えないでしょう。
出力結果、つまりコンパイルされた結果の可読性はどうでもいいかな。
どうせデバッグはコンパイル前でやるんだし、出力された結果を見ることはない。
- 908 ：デフォルトの名無しさん：2015/10/17(土) 20:25:37.47 ID:/J6P+2iK
- ネイティブのが何倍か速かったわ
コードは160kb増えて41倍になった模様
http://qiita.com/k--kato/items/96566a40f6b4761a5fa1
- 909 ：デフォルトの名無しさん：2015/10/17(土) 20:34:57.36 ID:ae7C+ipJ
- でもそれはあくまで現時点でのEdgeにおいてでしょ
もうしばらく立って十分に最適化が進んだ頃にネイティブ実装と
変換噛ませたレガシーIE上での動作を比べたら雲泥の差だと思うよ。
- 910 ：デフォルトの名無しさん：2015/10/17(土) 20:57:21.42 ID:/J6P+2iK
- Promise,yield,awaitといった非同期API全般がそもそもコールバックよりかなり遅いから
そんなにパフォーマンスが気になるなら全部コールバックで書けということになる
ネイティブサポートに盲目的になりすぎ
- 911 ：デフォルトの名無しさん：2015/10/17(土) 20:57:40.84 ID:pib/Nfzj
- >>908
41倍じゃなくて、+160KBだけなのね。
- 912 ：デフォルトの名無しさん：2015/10/17(土) 20:59:00.90 ID:pib/Nfzj
- プログラミングの世界は昔から
「遅いが生産性が高い技術」に移行していっているんだよ。
- 913 ：デフォルトの名無しさん：2015/10/17(土) 21:23:05.66 ID:/J6P+2iK
- >>911
出力見てないからどの程度比例増加するかわからんが定数増であってほしい
>>912
そういうことだな
ただ1回非同期処理するごとにv8が最低1ms遅延してたはずだから単純に置換できない落とし穴のある技術だよ
乱用して同期的なコールバックを非同期化すると1msで済んでたのが100ms以上になりかねない
- 914 ：デフォルトの名無しさん：2015/10/17(土) 22:42:30.65 ID:UgE8X6ba
- githubでspecのtypo修正が始まったり新規提案に対してES7にはもう間に合わないなんて
コメントがついたりしているからそろそろfixなのかな
- 915 ：デフォルトの名無しさん：2015/10/18(日) 04:52:39.08 ID:wSkksV4R
- async自体の仕様はfix出来るかもしれないが、
Composition Functionsの問題は全く進展してないかな。
https://esdiscuss.org/notes/2015-03/Composition%20Functions.pdf
- 916 ：デフォルトの名無しさん：2015/10/19(月) 19:01:24.35 ID:4SJt7LcL
- Firefox(Nightly)でSIMDが使えるようになってたからいじってみたらだいぶ仕様が変わってる
a.xがSIMD.Float32x4.extractLane(a, 0)と書かないと駄目になってた…
あんたらはいつだって正しいよ…
- 917 ：デフォルトの名無しさん：2015/10/19(月) 19:11:56.01 ID:oKvofSGv
- extractLaneは性能の問題というよりも要素数の問題が大きいと思う。
アルファベットの割当は4レーン以外は非現実的だ。
shuffleに渡すの定数に関しての仕様変更もそう。
だから逆に言えば4レーンの物に関しては必要と思えばゲッターを定義すればいいと思う。
今のエンジンの賢さならオーバーヘッドはかからないだろう。
- 918 ：デフォルトの名無しさん：2015/10/19(月) 19:20:20.28 ID:4SJt7LcL
- パフォーマンスが気になる場合はスレッド(WebWorker)使わないと根本的な解決にならないでしょ
別にworker作ってその中で非同期APIを使うのがパフォーマンスと可読性の両方を満たせる
(workerは制約が多いから必ずworkerに出来るとは限らないけど)
- 919 ：デフォルトの名無しさん：2015/10/19(月) 19:27:40.78 ID:4SJt7LcL
- >>917
> アルファベットの割当は4レーン以外は非現実的だ。
確かにゲーム用と言う訳じゃなくて汎用のものだからね…
var vec4 = SIMD.Float32x4;
var vec4.getX = vec4.extractLane;
とかして使うのが普通になるんだろう
- 920 ：デフォルトの名無しさん：2015/10/19(月) 19:31:18.01 ID:4SJt7LcL
- >>919
> var vec4.getX = vec4.extractLane;
間違えた…完全にアホな事になってるな
ちゃんとやるにはvec4をclassでちゃんと定義するとこからやらないと駄目だ
- 921 ：デフォルトの名無しさん：2015/10/20(火) 08:39:27.80 ID:lH+3yqb/
- >>919
それかSIMD.Float32x4.prototypeにゲッターを定義すればいい。
- 922 ：デフォルトの名無しさん：2015/10/24(土) 22:39:43.70 ID:njQlVqZk
- wiki.ecmascript.orgはまだ復旧しないのか…
- 923 ：デフォルトの名無しさん：2015/10/25(日) 04:24:22.48 ID:G+I5hghq
- 別に必要ないしな……
- 924 ：デフォルトの名無しさん：2015/10/25(日) 05:08:41.12 ID:jEvHtWyD
- stage0にある提案のいくつかがあそこへリンクしてるんだよなあ
- 925 ：デフォルトの名無しさん：2015/10/25(日) 16:54:51.73 ID:29qKD1yd
- 一時期毎日のように見てたから俺はもう大方頭に入ってるが
見たければWeb Archiveでも利用したら？
- 926 ：デフォルトの名無しさん：2015/10/27(火) 22:41:23.31 ID:vRn8Dsq1
- 提案者が別のところにupしなおさないとstage0のままだろうな
- 927 ：デフォルトの名無しさん：2015/10/28(水) 00:09:39.16 ID:k0fiQc1y
- stageが3になれば実装が推奨されるとなっているが実際には特に新しい概念の仕様では
実装されることがstageを上がるために必要なのもあり結局は実装側の興味次第となっている
SMやV8の先進実装、最近ではDo Expressionsを見ても分かるが
仕様がきっちりできる前に実装されることも良くある
極論言えばもはやJSはLSなんだからECMAの仕様になるかは全く重要でない
W3CのHTML仕様と同じくESはあくまで毎年LSのスナップショットを作成していくだけ
今でもその徴候があるがこれから仕様が大きく広くなってくると
どんどん各ベンダの対応状況にバラつきが出てくるようになるのは間違いない
かつてのMSのように今後暴走するのは世界シェア50％を達成したChromeやNodeを握っているV8だろう
時代は繰り返されるものだから仕方がないが
- 928 ：デフォルトの名無しさん：2015/10/29(木) 08:50:39.73 ID:hDFjXv2f
- >>927
あなたのいうのはデファクトスタンダード。
標準化されずに先行実装/独自拡張が進む事をLSとは呼ばない。
先行実装されることで仕様が固まる事もあるので先行実装が無駄とは思わないが。
- 929 ：デフォルトの名無しさん：2015/10/29(木) 11:12:08.04 ID:OVaYPdng
- それは違うでしょ。
デファクトスタンダートとは明確に決められているわけではないが、実質の共通の仕様であって、
昔みたいなクローズドな独自実装が元で産まれることはあるが、現在では基本的には真反対の概念になる。
- 930 ：デフォルトの名無しさん：2015/10/29(木) 12:51:32.63 ID:kPkPllsj
- >>929
LSとデファクトスタンダードが別概念なのは共通認識として>>927の概念はどっちなのか、という話かと。
「ECMAの仕様になるかは全く重要でない」というのは標準化されなくても全く困らないといっているわけだよね。
実装が仕様に先行し、仕様がただのスナップショットになるからLSだと彼は評しているけど、それは違うでしょ。
スナップショットになるならその時点で複数の実装間で挙動の差異がなくなるようにしていなければならない。
実装が仕様に先行するわけだから共通仕様があるわけでもなし、どの実装に挙動を合わせるのか、という問題になる。
その問題をクリアした結果がデファクトスタンダード。
デファクトスタンダードばかりが ES 仕様に取り込まれたらinnerHTMLのような曖昧な仕様ばかりになるけど、それは好ましいものではない。
ES には標準化という重要な役割がある事は間違いない。
ECMA を軽視する理由がどこにあるというのか。
- 931 ：デフォルトの名無しさん：2015/10/29(木) 13:44:09.08 ID:YyOU4m2s
- それは違うでしょ。
普通デファクトというと、
例えばES6以前でのsloppy modeでのブロック文中の関数宣言の振る舞いとかを指す。
確かに厳密に言えばどの仕様を採用するかという点等においてデファクトとも言えるが、
それを言い出すとそれこそWeb APIだってなんだって多くの物事がデファクトで決まってる。
それは独占でない競争や自然淘汰がある世界では至極当然の意味のない言葉であって、
実質の標準と公式の標準が一致する時に公式をデファクトと呼ぶことと同じく屁理屈にすぎない。
あえてデファクトという言葉を使うのであれば上の例のように、
本当に明文化されてなく公開された仕様もないけど皆挙動を合しているといったケース以外は不相当。
そしてここで重要なのは、今まではECMAメンバが提案しECMAサイトで管理してECMAが策定する
独占集中状態から徐々にそうでなくなってきているという点。
つまりECMAの理から外れた物事だからと言ってデファクトとは呼べない。呼ぶ意味がない。
それと彼はESではなくJS→ブラウザに乗ったJSについて話しているのだからなおのこと。
Angularなどが前から使ってるO.oのように、ブラウザベンダは好きに仕様を作り、
好きなタイミングで仕様を取り込むことができる。
それにはECMAがいつ仕様にしただとかstageはいくつかだとかは関係ない。
stageが4になるのには2つの実装が必要というW3Cと同じステップをとっている点や、
仕様は毎年決まったじきに出すということからも分かるが、
結局はECMA標準は現実の後追いのスナップショットでしか無くなってしまったんだよ。
そしてその傾向は徐々に強まる一方。
- 932 ：デフォルトの名無しさん：2015/10/29(木) 19:21:35.13 ID:L/sUjg9T
- >>931
WHATWG主導のDOM関連仕様はLSだが、ESはLSではない。
スナップショットがLSとか、いろいろと考え方がおかしい。
- 933 ：デフォルトの名無しさん：2015/10/30(金) 00:04:39.98 ID:Cv/9GOcj
- スナップショットがLSとか誰が言ってるんだろう？
ようはブラウザが実装するJSはブラウザの意向こそが標準ということで、
現在の実装こそがデファクトのLSということじゃないのか
- 934 ：デフォルトの名無しさん：2015/10/30(金) 07:34:50.97 ID:lKKv05eK
- >>933
・どのブラウザの意向？
・「現在の実装」とはどれ？
・「LS」というがどの辺がスダンダード？
・「JavaScript」は使用の名前ですらないけど、どういう意味？
突込みが追いつかない。
- 935 ：デフォルトの名無しさん：2015/10/30(金) 08:02:25.58 ID:rpRw3S4z
- JavaScriptは例えばwhatwgでLS仕様にされてるじゃん。
- 936 ：デフォルトの名無しさん：2015/10/30(金) 08:25:35.89 ID:lKKv05eK
- WHATWGが定めるのは https://spec.whatwg.org/ だけ。
ECMAScript の基盤となる仕様はない。
- 937 ：デフォルトの名無しさん：2015/10/30(金) 09:15:12.42 ID:rpRw3S4z
- 誰もECMAScriptの基盤となる仕様については話してないでしょう。
それならECMAScriptなのにECMAは関係ないとかわけがわからないじゃないか。
そうじゃなく最初からJavaScript, a.k.a. Web ECMAScriptについて話されてるじゃん。
ブラウザが実装するESの実情について話されてるんでしょ。
- 938 ：デフォルトの名無しさん：2015/10/30(金) 18:38:59.38 ID:CDEbnMq0
- >>937
その仕様は後方互換性の為に定められたもの。
規定されている機能は非推奨とされる機能ばかりなわけで次期ESに影響を及ぼす仕様ではない。
- 939 ：デフォルトの名無しさん：2015/10/30(金) 19:48:12.05 ID:lZRY1Ynm
- 話が噛み合ってないな
そもそも極論言えばESはどうでもいいという話なのに何故時期ESがどうのこうのという話が出てくるのだろう？
それと時期ESに影響をもろ及ぼしてるんだが
例えばHTMLコメントの件は最初WhatWGのJS仕様に乗っていたがES6に移動しただろ
- 940 ：デフォルトの名無しさん：2015/10/30(金) 21:26:40.29 ID:p3yny4dW
- ここは、とにかくデファクトスタンダードって書き込むスレですか？
- 941 ：デフォルトの名無しさん：2015/10/30(金) 22:16:42.03 ID:eJ2e2Hn1
- 仕様がどうとか、身にならないことばかりしてるなーｗ
どうでもいいだろ。重要なのは今のブラウザで
動くかどうかだよ。
- 942 ：デフォルトの名無しさん：2015/10/30(金) 22:32:31.87 ID:PeA9n0do
- スレタイ読めない人なのか？
- 943 ：デフォルトの名無しさん：2015/11/02(月) 00:08:50.31 ID:MeN03+7y
- >>941
そーゆー話はここじゃなくてJSスレでどうぞ
- 944 ：デフォルトの名無しさん：2015/11/04(水) 18:20:25.40 ID:XE8xk1wx
- O.oが無くなるかもしれないのか……
個人的には今のAPIが完璧かは置いといてProxyとは別に必要な概念だと思うけどな
- 945 ：デフォルトの名無しさん：2015/11/05(木) 01:27:31.11 ID:tAlGc147
- >>939
馬鹿なことを言い続ければ誰とも話が合わなくても仕方がない。
- 946 ：デフォルトの名無しさん：2015/11/06(金) 12:28:17.01 ID:51omasux
- do expressionだんだんいいと思い始めてきた
- 947 ：デフォルトの名無しさん：2015/11/06(金) 17:48:20.36 ID:evwxNDA5
- do-while文の一部を再利用したと見れば自然だしな
- 948 ：デフォルトの名無しさん：2015/11/06(金) 19:33:27.15 ID:51omasux
- return do switchの絡みが魅力的
- 949 ：デフォルトの名無しさん：2015/11/08(日) 02:15:02.47 ID:magscoB0
- >>932
> WHATWG主導のDOM関連仕様はLSだが、ESはLSではない。
来日してるTC39の中の人がESはLiving Standardのようになってるって言ってた
- 950 ：デフォルトの名無しさん：2015/11/08(日) 04:28:24.34 ID:2RNLDzo4
- 仕様もデプロイし続けるのだ
- 951 ：デフォルトの名無しさん：2015/11/08(日) 11:28:06.15 ID:yM3b54Wh
- >>949
策定作業があるのにか?
Javascriptの方なら意味は分かるがな。
- 952 ：デフォルトの名無しさん：2015/11/08(日) 15:31:26.62 ID:daOWsaQZ
- ミーティングノートやディスカスを見ても分かるが
ESとJSは中の人でさえ明確に区別して無いしする意味も薄いだろう。
- 953 ：デフォルトの名無しさん：2015/11/08(日) 17:19:57.49 ID:vEEfyyEO
- >>951
TC39ってしってる？
- 954 ：デフォルトの名無しさん：2015/11/09(月) 10:59:00.07 ID:eWDwuT9c
- Object.observe ECMAScript Proposal to be Withdrawn
http://www.infoq.com/news/2015/11/object-observe-withdrawn
- 955 ：デフォルトの名無しさん：2015/11/10(火) 00:33:21.12 ID:CA3uylg6
- https://github.com/tc39/agendas/blob/master/2015/11.md
> iv. Update on Object.observe proposal
Updateねえ
- 956 ：デフォルトの名無しさん：2015/11/10(火) 19:29:41.41 ID:FVZ3wbHi
- Stageが１個下がるくらいかな？
- 957 ：デフォルトの名無しさん：2015/11/10(火) 22:38:54.99 ID:ZBK/pyIG
- withdrawnが了承されたら消えるのでは
- 958 ：デフォルトの名無しさん：2015/11/11(水) 01:10:05.42 ID:SO5jAdhG
- その仕様を支持する人がいる限り消えることは無いんじゃない？
例え表立った代表者がいなくてもstage 0ではいられるみたいだし。
- 959 ：デフォルトの名無しさん：2015/11/11(水) 16:16:33.94 ID:oO+3Zy7C
- ECMAScript 2015はなぜ策定まで時間がかかったか？
仕様策定のリーダー、アレン・ワーフスブラック氏に聞く
http://codezine.jp/article/detail/9071
- 960 ：デフォルトの名無しさん：2015/11/12(木) 03:37:15.29 ID:lozeCk1H
- あれこの人もMS出身だったのか
- 961 ：デフォルトの名無しさん：2015/11/12(木) 04:04:33.97 ID:glwMRaFe
- 重鎮はモジラ(ネスケ)かMSにいておかしくない
- 962 ：デフォルトの名無しさん：2015/11/12(木) 08:30:49.36 ID:UoAFOwbi
- >>960
一時的にいただけで出身といえるほどじゃない。
専門はsmalltalkとJavaだった。JavaだとGWTとか。
OOPの世界では奥さんの方が有名。
- 963 ：デフォルトの名無しさん：2015/11/12(木) 08:48:09.39 ID:35mMQpUa
- >>962
え、もしかしてレベッカさん？
- 964 ：デフォルトの名無しさん：2015/11/12(木) 10:10:20.22 ID:iZs6jymX
- / ／ ､ ＼
/ / ＼ ､ ヽ
i / / / | ヽ ヽ ヽ
|/ /‐十‐ ､ﾉ| ＿ } ヽ ヽ ヽ
,r‐ ''"|{ l ／/ メ/ | ´ ﾒ l l ', ヽ
,. ‐ ´ |'､ |/ L. ､ | ／|. / | | }
,. '´＿ | ＼ ､l〃´ ｀ヾ ﾉ-‐ ,.-‐=､ﾚ∧ / / /
-─‐ァ| l!ヽヽ､| ::::::: ´ .....`´| ソ イ ／
＿＿ z‐"´ |l l｀ﾍ _ ::::: l ´| ﾉ'´
/´ ｀ヽ､ |__ﾉ |!＼ / ￣ } 人 l|
! ヽ ヾ ヾ⌒t､__i＞ゝ､__ ノ_,,.. -彳l l │
｀ヽ､ ヽ ヽ | ｀:::ヽト､ ト､夂‐-､! ! l|
＼ ﾍ ﾐ| l::::::::l 〉:|＼＿＿_／=≡〉ﾉ ﾉﾊ
ヽ ∧ヽ／＼l l::::＼＼::::::::｀√｀ヾ､丿
- 965 ：デフォルトの名無しさん：2015/11/12(木) 19:30:45.61 ID:y1aaFWGg
- >>963
そう
- 966 ：デフォルトの名無しさん：2015/11/15(日) 19:59:40.17 ID:XRSDwhWF
- O.oはミーティングを待たずしてstage表から削除されたか
- 967 ：デフォルトの名無しさん：2015/11/17(火) 19:02:53.36 ID:gR5JnX5o
- おいヤメろ
俺が作ったゲームエンジンが破綻するやろ
なんだよGoogle信じてたのに
- 968 ：デフォルトの名無しさん：2015/11/17(火) 21:18:46.84 ID:HdIuV45w
- Polyfillあるんだから使っとけ
- 969 ：デフォルトの名無しさん：2015/11/17(火) 21:19:36.61 ID:ue9cUm18
- 現地17日だから日本だと明朝から会議スタートか
agendas見ると正規表現関連の議題が多いな
- 970 ：デフォルトの名無しさん：2015/11/18(水) 10:38:56.88 ID:wLqg2NVj
- >>968
Polyfill使う位ならこんな設計にしなかったし、
特にモバイルでパフォーマンスが致命的
- 971 ：デフォルトの名無しさん：2015/11/18(水) 11:33:05.99 ID:AJibgoSD
- 策定されてもいない ES7 で運用する事がそもそもの誤り
- 972 ：デフォルトの名無しさん：2015/11/18(水) 17:58:06.95 ID:db8O1sPx
- いやあでふぉで使えるようになったらそりゃ使うでしょ
ESなんだろうて関係ないし
- 973 ：デフォルトの名無しさん：2015/11/18(水) 18:41:41.63 ID:AJibgoSD
- 使ってもいいけど、後で機能が削除されたり変更されても文句をいわない
それだけの手間がかかる事を覚悟してから使うべき
- 974 ：デフォルトの名無しさん：2015/11/18(水) 21:50:16.78 ID:nxmkjiRg
- >>973
本気で文句を言ってるわけ無いでしょ……
ちょっと大げさに驚いてみただけじゃん酷いな
- 975 ：デフォルトの名無しさん：2015/11/19(木) 02:15:12.82 ID:fF+cq/BY
- 悪い冗談だな
- 976 ：デフォルトの名無しさん：2015/11/23(月) 21:58:10.41 ID:ehFsbVTs
- ESのプロポーサル増えてきたけど、
これ今の倍くらいになってきたらもう２ヶ月に一度のミーティングで取り扱っていくの限界が出るよね。
まあ今でもオンラインでほぼ意見が纏まったのを追認するだけになりつつあるけど、そうやってしのいでいくのかな。
- 977 ：デフォルトの名無しさん：2015/11/23(月) 23:37:08.80 ID:0Hw9c98a
- 議論するのに会わないといけないというものでもない。
- 978 ：デフォルトの名無しさん：2015/11/23(月) 23:55:45.76 ID:HADEXuLs
- そりゃ議論は適当にできるけど、メンバーのコンセンサスを取るのは難しいでしょ
それこそLivingStandardみたいにするならできるけど、そうじゃないなら
定期的に限られた時間で決を取るということがどうしても必要
- 979 ：デフォルトの名無しさん：2015/11/24(火) 09:40:10.36 ID:Z+81xDV1
- >>954の日本語訳
ECMAScriptプロポーザルのObject.observeは撤回される
http://www.infoq.com/jp/news/2015/11/object-observe-withdrawn
- 980 ：デフォルトの名無しさん：2015/11/30(月) 21:29:03.77 ID:/Y7Ge2JV
- aaaaa
- 981 ：デフォルトの名無しさん：2015/11/30(月) 21:29:51.68 ID:/Y7Ge2JV
- aaaaa
- 982 ：デフォルトの名無しさん：2015/12/02(水) 09:28:37.86 ID:kHNhoSoS
- 新スレまだー?
- 983 ：デフォルトの名無しさん：2015/12/02(水) 11:08:26.58 ID:BdoQdRIv
- まだ早い
- 984 ：デフォルトの名無しさん：2015/12/02(水) 12:41:18.79 ID:PK20+i4Q
- そんなわけで立てた
http://peace.2ch.net/test/read.cgi/tech/1449027632/1
- 985 ：デフォルトの名無しさん：2015/12/02(水) 13:18:14.55 ID:z6t/clbO
- テンプレが一切更新されてないじゃねーか
埋め
- 986 ：デフォルトの名無しさん：2015/12/02(水) 16:02:06.23 ID:RgXqYJb4
- >>983
980超えたスレは24時間以上レスないと落ちるので…
lud20190719034437このスレへの固定リンク： http://5chb.net/r/tech/1325448978/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
ブックマークへ |
|---|
全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像
↓「ECMAScript デス 4YouTube動画>4本 」を見た人も見ています：
・ECMAScript デス 6
・JavaScript 4
・【node.js】サーバサイドjavascript 4【io.js】
・JavaScript コメントの謎
・JavaScript Tips コレクション
・JavaScript の質問用スレッド vol.123
・+ JavaScript のお題用スレッド +
・JavaScript の質問用スレッド vol.125
・+ JavaScript の質問用スレッド vol.124 +
・+ JavaScript の質問用スレッド vol.125 +
・+ JavaScript の質問用スレッド vol.126 +
・+ JavaScript の質問用スレッド vol.61 +
・ +JavaScript の質問用スレッド vol.42 +
・JavaScript ライブラリ総合質問所 vol.4
・+ JavaScript の質問用スレッド vol.121 +
・+ JavaScript の質問用スレッド vol.105 +
・+ JavaScript の質問用スレッド vol.120 +
・+ JavaScript の質問用スレッド vol.129 +
・+ JavaScript の質問用スレッド vol.129 +
・+ JavaScript の質問用スレッド vol.129 +
・+ JavaScript の質問用スレッド vol.122 +
・+ JavaScript の質問用スレッド vol.144 +
・+ JavaScript の質問用スレッド vol.130 +
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.122 +
・+ JavaScript の質問用スレッド vol.143 +
・+ JavaScript の質問用スレッド vol.127 +
・+ JavaScript の質問用スレッド vol.124 +
・+ JavaScript の質問用スレッド vol.121 +
・+ JavaScript の質問用スレッド vol.141 +
・+ JavaScript の質問用スレッド vol.132 +
・+ JavaScript の質問用スレッド vol.124 +
・+ JavaScript の質問用スレッド vol.141 +
・+ JavaScript の質問用スレッド vol.118 +
・+ JavaScript の質問用スレッド vol.125 +
・+ JavaScript の質問用スレッド vol.119 +
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.126 +
・+ JavaScript の質問用スレッド vol.130 +
・+ JavaScript の質問用スレッド vol.129 +
・+ JavaScript の質問用スレッド vol.138 +
・+ JavaScript の質問用スレッド vol.139 +
・+ JavaScript の質問用スレッド vol.142 +
・+ JavaScript の質問用スレッド vol.136 +
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.131 +
・+ JavaScript の質問用スレッド vol.134 +
・+ JavaScript の質問用スレッド vol.135 +
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.122 +
・+ JavaScript の質問用スレッド vol.142 +
・+ JavaScript の質問用スレッド vol.133 +
・次世代言語Part8[Haskell Rust Kotlin TypeScript]
・【node.js】サーバサイドjavascript 5【Nashorn】
・【JavaScript系】 NILScript 【AutoHotkey風】
・【node.js】サーバサイドjavascript 2【Rhino】
・【jQuery】JavaScript ライブラリ総合質問所 vol.3
・【jQuery】JavaScript ライブラリ総合質問所 vol.1
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・+ JavaScript & jQuery 質問用スレッド vol.8 +
・+ JavaScript & jQuery 質問用スレッド vol.7 +
・JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]
08:02:23 up 31 days, 18:26, 0 users, load average: 11.03, 10.24, 10.05
in 0.0207839012146 sec
@0.0207839012146@0b7 on 011222 |