08/11/21 18:05:33
>>471
URLﾘﾝｸ(wiki.mozilla.org)
URLﾘﾝｸ(hg.mozilla.org)
URLﾘﾝｸ(steps.dodgson.org)
475:デフォルトの名無しさん
08/11/22 12:51:48
3.1にObject.seal()入るんだ。freeze()も。
よかった。
476:デフォルトの名無しさん
08/11/23 05:15:49
前方互換が無くなるだけで不要な機能だろ
無用な方言を増やすだけの概念
477:デフォルトの名無しさん
08/11/23 09:13:33
class, moduleその他、
動的に変って欲しくないオブジェクトのために必要なんだよ。
478:デフォルトの名無しさん
08/11/23 22:17:26
seal も freeze も、Object.defineProperty の糖衣構文だと思う
やってることは「内部プロパティを変更」という点で共通してる
あるととっても便利（特に [[Enumerable]] の変更）
479:デフォルトの名無しさん
08/11/24 03:15:50
便利かどうかなんて訊いた覚えはないがありがとう。
＞“前方互換が無くなるので不要な機能”
forEach とかクラスメソッドは 3.0 でも Array や prototype を事前に拡張することで対応できる。
しかし Object.defineProperty は？
IE6 と IE7 で動かすためには __*** とか適当なプロパティ作って、
forEach をそれを見るような実装で上書きするような実装しか今俺には思い浮かばない。
とここまで forEach がある Array ならいいが
Object には Enumerable 関数は考えられてない（アホだよな）から
for in に対応できるような実装は不可能。
4.0 から 3.1 にした意味は？中の人は何も学習してないんだろうか。
480:デフォルトの名無しさん
08/11/24 11:32:42
>>478
seal, freezeに関しては、
重要なのは提供方法ではなく、
・Objectが[[extensible]]でなくなる
・propertyが[[flexible]]、[[writable]]でなくなる
そのための方法があること。
これでライブラリー内部のエラー処理がずいぶんと楽になる。
ライブラリーユーザ側のデバッグも。
[[enumerable]]に関しては、
今のままではdirty hackの巣窟になりそうで、
何とかしないといけないとは思うけど、
前方互換の問題があるから慎重にやるべきだと思う。
特にメタな仕組みを持つライブラリに影響が大。
for in抽象はもうちょっとうまく整理するやり方があったと思う。
Javaのcontrol invacation syntaxみたいな。
481:デフォルトの名無しさん
08/11/25 02:52:09
Object.forEach みたいな関数が出てきたとして、
Object はルート要素なんだから、全てのオブジェクトに forEach が無いとおかしい罠。
元はと言えば Object をハッシュのように使った“慣習”のツケなんだけど…
482:デフォルトの名無しさん
08/11/25 09:28:53
>>481
> 元はと言えば Object をハッシュのように使った“慣習”のツケなんだけど…
kwsk
実装自体は連想配列なのに、使ってはならない理由があったの？
483:デフォルトの名無しさん
08/11/25 10:03:02
Array のようにちゃんとデータ型として規定されてれば、
メソッドやプロパティの名前空間とぶつかるような実装にはならなかっただろうし、
enumerable のアリナシに四苦八苦することも少なかっただろうって話
484:デフォルトの名無しさん
08/11/25 10:44:37
要はHashとかDictionaryとかいう型を別に作っておけばよかったということだな
中身はObjectとまったく一緒でいいけど
485:デフォルトの名無しさん
08/11/25 10:53:50
特殊な組み込み型を用意するんじゃなくて、
そういうものを実装できる機構があればいい。
[[enumerable]]に関しては、
>>481の言うようにforEachはどのObjectも持つようにして、
for inはforEachメソッドを呼び出すように再整理するのがいいと思う。
Property attributeによる整理で基本的にはうまくいっている。
486:482
08/11/25 12:16:11
thx
> 要はHashとかDictionaryとかいう型を別に作っておけばよかったということだな
言われてみれば激しく同意だなー
487:デフォルトの名無しさん
08/11/25 18:04:15
>>484
そうすると、ESのESたる特徴がなくなってしまいますな。
つーか、それ、何のJavaの亜流？って感じになっちまう。実際なりそうだけど。 orz
488:デフォルトの名無しさん
08/11/26 09:44:23
ボタンAを押すと自動的にボタンBを押すスクリプトはどう書けばよろしいのでしょうか？
489:デフォルトの名無しさん
08/11/26 11:06:05
>>488
click()
たぶんスレ違いだからJavaScriptスレ池
490:488
08/11/26 13:36:50
いえ、ecmaです。
よろしくお願いします
491:デフォルトの名無しさん
08/11/26 13:45:27
ECMAScriptの仕様にボタンはない
492:デフォルトの名無しさん
08/11/26 17:09:54
>>488
スレ違
たぶんこっち↓
+ JavaScript の質問用スレッド vol.67 +
ｽﾚﾘﾝｸ(hp板)
493:デフォルトの名無しさん
08/11/26 18:30:20
> for in抽象はもうちょっとうまく整理するやり方があったと思う。
> Javaのcontrol invacation syntaxみたいな。
> for inはforEachメソッドを呼び出すように再整理するのがいいと思う。
旧 ES4 だと iterator::values() iterator::items() iterator::keys()
とか提案されてたが、ボツったわけでどーすんのやら。
URLﾘﾝｸ(wiki.ecmascript.org)
494:488
08/11/27 12:19:04
ありがとうございます。
行ってみます