私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.137 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
単純に、オブジェクトを辞書みたいに使う際、
たまたま、__proto__ と言うキーを使うと、ハマる
だから、Haxe では、キー文字列の先頭に、@ を付ける
a → @a
__proto__ → @__proto__
これで、誤動作しない
たまたま、__proto__ と言うキーを使うと、ハマる
だから、Haxe では、キー文字列の先頭に、@ を付ける
a → @a
__proto__ → @__proto__
これで、誤動作しない
>>501
いや、自然でしょ
例えばget x()を定義しててもプライベートメンバを_xとかにする必要なく
this.#xとできたり良いこともたくさんあるでしょ
private.xみたいにアクセスするのも変だし
パフォーマンスの問題がなかったとしても
クラスメソッド中だけthis下のプライベートメンバにアクセスできるようにするのは
JS的に不自然極まりないし
いや、自然でしょ
例えばget x()を定義しててもプライベートメンバを_xとかにする必要なく
this.#xとできたり良いこともたくさんあるでしょ
private.xみたいにアクセスするのも変だし
パフォーマンスの問題がなかったとしても
クラスメソッド中だけthis下のプライベートメンバにアクセスできるようにするのは
JS的に不自然極まりないし
perlや、rubyのインスタンス変数@xみたいな変数名の一部に文法的な意味持たせる設計ほんと嫌い。
あと@にしなかったのはデコレータに既に予約されてたからだと。
なんかこういう行き当たりばったりな機能追加はrubyのオブジェクトリテラルまわりや山ほどあって一貫性がまるで無い関数(プロシージャ含む)の定義法/用法/挙動/変換のカオスを彷彿とさせて嫌な予感しかしない。
所詮class構文ゴリ押し勢だからruby出身の低級プログラマが我田引水で適当に決めてるんだろ。
だからclass構文まわりは嫌いなんだ。
あと@にしなかったのはデコレータに既に予約されてたからだと。
なんかこういう行き当たりばったりな機能追加はrubyのオブジェクトリテラルまわりや山ほどあって一貫性がまるで無い関数(プロシージャ含む)の定義法/用法/挙動/変換のカオスを彷彿とさせて嫌な予感しかしない。
所詮class構文ゴリ押し勢だからruby出身の低級プログラマが我田引水で適当に決めてるんだろ。
だからclass構文まわりは嫌いなんだ。
iterator取り出すのさえx[Symbol.iterator]と書かせてるんだから
宣言時はprivate xで参照時はthis[Symbol.private]('x')なりthis[Symbol.private].xなりでええやろ。
外部からのアクセス時はエラーで。
面倒なやつは無理して使わなくていいよ。
変数名中の記号の有り無しでやるよりずっとマシ。
宣言時はprivate xで参照時はthis[Symbol.private]('x')なりthis[Symbol.private].xなりでええやろ。
外部からのアクセス時はエラーで。
面倒なやつは無理して使わなくていいよ。
変数名中の記号の有り無しでやるよりずっとマシ。
それだと使いにくい
encapsulationを促進するのが目的だから短く書けることも重要視されたんだろ
encapsulationを促進するのが目的だから短く書けることも重要視されたんだろ
ほんまそう
別にprivate.x == private(this).xと記号を使わないこともできたが
privateなんて長すぎるからな
別にprivate.x == private(this).xと記号を使わないこともできたが
privateなんて長すぎるからな
短く書くために記号とか腐ってるなｗｗｗ
rubyから出てこないでほしい。
あーキモイキモイ
rubyから出てこないでほしい。
あーキモイキモイ
おじいちゃん
あの長く書くことが正義だったJavaでさえアロー演算子とか導入してるんだよ
あの長く書くことが正義だったJavaでさえアロー演算子とか導入してるんだよ
変数名にってことだろ。
構文や演算子の記号は誰も文句言ってない。
構文や演算子の記号は誰も文句言ってない。
同様のクソ提案
Extended Numeric Literals
http://github.com/tc39/proposal-extended-numeric-literals
例)
document.querySelector("#foo").style.fontSize = 3~px;
なんだよ~て。perl化待ったなしｗｗｗ
Object.freeze and Object.seal syntax
http://github.com/keithamus/proposal-object-freeze-seal-syntax/
freeze
const foo = {#
a: {#
b: [# "some string!" #]
#}
#}
seal
sealing of an object
const foo = {|
a: {|
b: [| "some string!" |]
|}
|}
ええ加減にせえよ。
Extended Numeric Literals
http://github.com/tc39/proposal-extended-numeric-literals
例)
document.querySelector("#foo").style.fontSize = 3~px;
なんだよ~て。perl化待ったなしｗｗｗ
Object.freeze and Object.seal syntax
http://github.com/keithamus/proposal-object-freeze-seal-syntax/
freeze
const foo = {#
a: {#
b: [# "some string!" #]
#}
#}
seal
sealing of an object
const foo = {|
a: {|
b: [| "some string!" |]
|}
|}
ええ加減にせえよ。
>>511
変数名？何いってんだ？
o.#pと書くということは
([[classWeakMap]].get(o)||{}).p
と言う効果をもたらすものであって
変数名をプロキシしてるわけではない
そしてこれは「.#」演算子と考えても妥当
変数名？何いってんだ？
o.#pと書くということは
([[classWeakMap]].get(o)||{}).p
と言う効果をもたらすものであって
変数名をプロキシしてるわけではない
そしてこれは「.#」演算子と考えても妥当
改めて考えると#案外いいかもと思えてきた
private x;とかだと冗長
private x;とかだと冗長
>>502
__proto__ 付のオブジェクトを生成してるのが問題
__proto__ 付のオブジェクトを生成してるのが問題
google analyticsのjavascriptって、埋め込まれたページからアクセスするpdfやxlsへの直リンクって統計の対象になる？
埋め込まれたページまでしかできないかと思ってたんだけど、そのページに押されたリンクまで検知できるの？
埋め込まれたページまでしかできないかと思ってたんだけど、そのページに押されたリンクまで検知できるの？
ES4時代からアイディアがあって
5年以上、物によっては10年かけて皆が話し合って
色んな場所で沢山プレゼンされて
ようやく見通しが見えてきた仕様を
欠片も分かってないくせにここで批判するやつ
お前がええ加減にせえよ。
ただ関心をもったという点は褒めることができる
だから意見があるんならまだ半年以上猶予があるんだから
今からでもES Discussにスレッド立ててこい
何も新規性のない不満垂れてもボッコボコにされるだけだがな
5年以上、物によっては10年かけて皆が話し合って
色んな場所で沢山プレゼンされて
ようやく見通しが見えてきた仕様を
欠片も分かってないくせにここで批判するやつ
お前がええ加減にせえよ。
ただ関心をもったという点は褒めることができる
だから意見があるんならまだ半年以上猶予があるんだから
今からでもES Discussにスレッド立ててこい
何も新規性のない不満垂れてもボッコボコにされるだけだがな
Q. どうして@ではないのですか？
A. デコレータに取られちゃってた(ﾃﾍﾍﾟﾛｗｗｗ
A. デコレータに取られちゃってた(ﾃﾍﾍﾟﾛｗｗｗ
ES住民ならデコレータは関係なく
大昔からプライベート廻りでは@と#を使った提案があったが
@の方が今のSymbolになった（仕様の@@がその名残）ので
今回の提案ではよりちょっとmap参照っぽくもあった（valueではなくnameのmapだが）#を使うほうが
これまでの10年間の歴史的な流れからいって【自然】ということが分かる
大昔からプライベート廻りでは@と#を使った提案があったが
@の方が今のSymbolになった（仕様の@@がその名残）ので
今回の提案ではよりちょっとmap参照っぽくもあった（valueではなくnameのmapだが）#を使うほうが
これまでの10年間の歴史的な流れからいって【自然】ということが分かる
http://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-was-the-sigil--chosen-among-all-the-unicode-code-points
>・@ was the initial favorite, but it was taken by decorators.
クソ雑魚マウントバカ「公式説明は不自然！」
ｗｗｗｗｗ
>・@ was the initial favorite, but it was taken by decorators.
クソ雑魚マウントバカ「公式説明は不自然！」
ｗｗｗｗｗ
言語作ってるやつが馬鹿だと思うのは、
記号なんて数が限られてるの最初からわかってるんだから
使えるからと言って後先考えずに使うなってこと
一文字で足りなくなるのわかってるんだから、最初から
記号＋1文字にしておけば良かったんだよ
例えば、@じゃなくて@@とかさ
記号なんて数が限られてるの最初からわかってるんだから
使えるからと言って後先考えずに使うなってこと
一文字で足りなくなるのわかってるんだから、最初から
記号＋1文字にしておけば良かったんだよ
例えば、@じゃなくて@@とかさ
>>520
@が好まれていたのは当初のprivate-(name->state)の流れを受けていた頃の話
つまりprivateを所謂プライベートシンボルを全面に出して実現しようという流れがまだ残ってたときの話で
その後統合されて今現在のprivateはWeakMapのようなもので実現する方向性だけしか残ってないから#の方が自然
そして今の仕様チャンピオンはTC39を去ったKevinのを引き継いでるだけなので
昔のことやES6前後のゴタゴタしていた辺りの詳しい話には細かくない
@が好まれていたのは当初のprivate-(name->state)の流れを受けていた頃の話
つまりprivateを所謂プライベートシンボルを全面に出して実現しようという流れがまだ残ってたときの話で
その後統合されて今現在のprivateはWeakMapのようなもので実現する方向性だけしか残ってないから#の方が自然
そして今の仕様チャンピオンはTC39を去ったKevinのを引き継いでるだけなので
昔のことやES6前後のゴタゴタしていた辺りの詳しい話には細かくない
ES2015ではsoft privateの実現にはsymbolが、hard privateの実現にはWeakMapが使える。
簡単に書きたいからという理由だけのために貴重な記号を消費しないでほしい。rubyじゃあるまいし。
簡単に書きたいからという理由だけのために貴重な記号を消費しないでほしい。rubyじゃあるまいし。
JSを2050年以降まで延命させたいと言うのなら分かるが
そろそろ壮年期だと思えば消費しどころだろ
そろそろ壮年期だと思えば消費しどころだろ
どんどん仕様を追加していくとC++みたいになる
そして飽きられて次の言語へ・・・
とならないかな
そして飽きられて次の言語へ・・・
とならないかな
C++の場合もうすでに飽きられてる
Googleとか大手は必ず自分たちでC++をマクロなどで改造して使ってるし
そうで無い人はもうとっくに諦めてる
俺たちは安定と速度を求めて不便なC++を使ってるのだから
便利な機能なんて誰も求めてねーよとなってるだけ
もう誰からも進化を期待されない段階になる前に機能を追加していく必要がある
Googleとか大手は必ず自分たちでC++をマクロなどで改造して使ってるし
そうで無い人はもうとっくに諦めてる
俺たちは安定と速度を求めて不便なC++を使ってるのだから
便利な機能なんて誰も求めてねーよとなってるだけ
もう誰からも進化を期待されない段階になる前に機能を追加していく必要がある
無節操に一貫性なく機能を追加していったrubyはもはや誰からも期待されてないけどな。
>>530
独善的な選民意識
ドキュメント軽視
ウィンドウズ蔑視
開発者がいくらMacやLinux使ってようが、ユーザーベースで8～9割はウィンドウズなわけよ。
今のPythonの利用シーンを見てみると、職業プログラマ以外が自分の仕事に活用するようなユースケースが多い。
こういうユースケースに、コミュニティのウィンドウズ蔑視は致命傷になったな。ドキュメント軽視も。そういう人たちは「コードが仕様だ！」とか言われてもハァ？だろうしな。
ま、Railsが沈むまでは生きてるよ。Railsのバッテリーとして。
独善的な選民意識
ドキュメント軽視
ウィンドウズ蔑視
開発者がいくらMacやLinux使ってようが、ユーザーベースで8～9割はウィンドウズなわけよ。
今のPythonの利用シーンを見てみると、職業プログラマ以外が自分の仕事に活用するようなユースケースが多い。
こういうユースケースに、コミュニティのウィンドウズ蔑視は致命傷になったな。ドキュメント軽視も。そういう人たちは「コードが仕様だ！」とか言われてもハァ？だろうしな。
ま、Railsが沈むまでは生きてるよ。Railsのバッテリーとして。
>>528,530
Rubyの敗因は開発側のリソース不足
公言したことが守れないのでコミュニティから見放された
でもJSのようにチートな企業がサポートしてないのでどうしようもない
まあ細々とやっていくことが必ずしも悪いことでは無いと思うが
Rubyの敗因は開発側のリソース不足
公言したことが守れないのでコミュニティから見放された
でもJSのようにチートな企業がサポートしてないのでどうしようもない
まあ細々とやっていくことが必ずしも悪いことでは無いと思うが
@ は、Python のデコレーター
Ruby では、@ はインスタンス変数で、@@ はクラス変数だから、
@@ をインスタンス変数として使うのは、不自然
Ruby では、@ はインスタンス変数で、@@ はクラス変数だから、
@@ をインスタンス変数として使うのは、不自然
>>535
VSCode, NOde.js の設定ファイルにでも、そういう項目があるんじゃね？
VSCode, NOde.js の設定ファイルにでも、そういう項目があるんじゃね？
デコレーターはPythonからというよりはJavaからだろ。
RoopyにいたってはRuviiの行き当たりばったり文法なんか何も参考にならないし誰も考慮してない。
RoopyにいたってはRuviiの行き当たりばったり文法なんか何も参考にならないし誰も考慮してない。
parentNodeとparentElementって違いあります？
単に親要素取得したい場合どっち使うべきですかね
単に親要素取得したい場合どっち使うべきですかね
あざす
じゃあparentNodeっていうプロパティは何のためにあるのですか
じゃあparentNodeっていうプロパティは何のためにあるのですか
いや、それくらい自分で調べろよ
調べて理解できないのならここで講義できるわけでもないしお前が分かるように伝えるすべがない
調べて理解できないのならここで講義できるわけでもないしお前が分かるように伝えるすべがない
Nodeのほうがプリミティブ。
用がなきゃエレメント使っときゃいい。
テキストノードいじらざるを得ないことはあったが…
用がなきゃエレメント使っときゃいい。
テキストノードいじらざるを得ないことはあったが…
たぶん、Element は、Node から派生した、子クラスか何かだろ
Nodeを使う事など、まずない！
Nodeを使う事など、まずない！
プロトタイプ継承だっつの。
クラスベースバカはrugyに引っ込んでろ！
クラスベースバカはrugyに引っ込んでろ！
クラスとプロトタイプは対立する概念ではない
最初からクラスシステムが提供されていてそれに縛られるのがクラスベース言語
プロトタイプベース言語でも構造化のためにやっぱりクラスシステムは必要になる場合も多い
ただそれに縛られていないと言うだけ
最初からクラスシステムが提供されていてそれに縛られるのがクラスベース言語
プロトタイプベース言語でも構造化のためにやっぱりクラスシステムは必要になる場合も多い
ただそれに縛られていないと言うだけ
クラスベースのクラスしかクラスが無いと思いこんでるやつのほうがよっぽどクラスベースバカというオチか
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について