元スレ+ JavaScript の質問用スレッド vol.137 +

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

501 = :

>>499
なんか後方互換性とかパフォーマンスのため消去法で#しかなかったっぽい
俺もダサいと思うがしょうがあるまい

502 = :

単純に、オブジェクトを辞書みたいに使う際、
たまたま、__proto__ と言うキーを使うと、ハマる

だから、Haxe では、キー文字列の先頭に、@ を付ける

a → @a
__proto__ → @__proto__

これで、誤動作しない

503 = :

>>501
いや、自然でしょ
例えばget x()を定義しててもプライベートメンバを_xとかにする必要なく
this.#xとできたり良いこともたくさんあるでしょ
private.xみたいにアクセスするのも変だし

パフォーマンスの問題がなかったとしても
クラスメソッド中だけthis下のプライベートメンバにアクセスできるようにするのは
JS的に不自然極まりないし

504 = :

perlや、rubyのインスタンス変数@xみたいな変数名の一部に文法的な意味持たせる設計ほんと嫌い。
あと@にしなかったのはデコレータに既に予約されてたからだと。
なんかこういう行き当たりばったりな機能追加はrubyのオブジェクトリテラルまわりや山ほどあって一貫性がまるで無い関数(プロシージャ含む)の定義法/用法/挙動/変換のカオスを彷彿とさせて嫌な予感しかしない。
所詮class構文ゴリ押し勢だからruby出身の低級プログラマが我田引水で適当に決めてるんだろ。
だからclass構文まわりは嫌いなんだ。

505 = :

もうちょっと日本語の勉強をした方がいい

506 = :

iterator取り出すのさえx[Symbol.iterator]と書かせてるんだから
宣言時はprivate xで参照時はthis[Symbol.private]('x')なりthis[Symbol.private].xなりでええやろ。
外部からのアクセス時はエラーで。
面倒なやつは無理して使わなくていいよ。
変数名中の記号の有り無しでやるよりずっとマシ。

507 = :

それだと使いにくい
encapsulationを促進するのが目的だから短く書けることも重要視されたんだろ

509 = :

短く書くために記号とか腐ってるなｗｗｗ
rubyから出てこないでほしい。
あーキモイキモイ

510 = :

おじいちゃん
あの長く書くことが正義だったJavaでさえアロー演算子とか導入してるんだよ

511 = :

変数名にってことだろ。
構文や演算子の記号は誰も文句言ってない。

512 = :

同様のクソ提案

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!" |]
|}
|}
ええ加減にせえよ。

513 = :

>>511
変数名？何いってんだ？
o.#pと書くということは
([[classWeakMap]].get(o)||{}).p
と言う効果をもたらすものであって
変数名をプロキシしてるわけではない
そしてこれは「.#」演算子と考えても妥当

516 = :

google analyticsのjavascriptって、埋め込まれたページからアクセスするpdfやxlsへの直リンクって統計の対象になる？
埋め込まれたページまでしかできないかと思ってたんだけど、そのページに押されたリンクまで検知できるの？

517 = :

ES4時代からアイディアがあって
5年以上、物によっては10年かけて皆が話し合って
色んな場所で沢山プレゼンされて
ようやく見通しが見えてきた仕様を
欠片も分かってないくせにここで批判するやつ
お前がええ加減にせえよ。

ただ関心をもったという点は褒めることができる
だから意見があるんならまだ半年以上猶予があるんだから
今からでもES Discussにスレッド立ててこい
何も新規性のない不満垂れてもボッコボコにされるだけだがな

518 = :

Q. どうして@ではないのですか？
A. デコレータに取られちゃってた(ﾃﾍﾍﾟﾛｗｗｗ

519 = :

ES住民ならデコレータは関係なく
大昔からプライベート廻りでは@と#を使った提案があったが
@の方が今のSymbolになった（仕様の@@がその名残）ので
今回の提案ではよりちょっとmap参照っぽくもあった（valueではなくnameのmapだが）#を使うほうが
これまでの10年間の歴史的な流れからいって【自然】ということが分かる

520 = :

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.


クソ雑魚マウントバカ「公式説明は不自然！」

ｗｗｗｗｗ

521 = :

言語作ってるやつが馬鹿だと思うのは、
記号なんて数が限られてるの最初からわかってるんだから
使えるからと言って後先考えずに使うなってこと

一文字で足りなくなるのわかってるんだから、最初から
記号＋1文字にしておけば良かったんだよ
例えば、@じゃなくて@@とかさ

522 = :

>>520
@が好まれていたのは当初のprivate-(name->state)の流れを受けていた頃の話
つまりprivateを所謂プライベートシンボルを全面に出して実現しようという流れがまだ残ってたときの話で
その後統合されて今現在のprivateはWeakMapのようなもので実現する方向性だけしか残ってないから#の方が自然
そして今の仕様チャンピオンはTC39を去ったKevinのを引き継いでるだけなので
昔のことやES6前後のゴタゴタしていた辺りの詳しい話には細かくない

523 = :

ES2015ではsoft privateの実現にはsymbolが、hard privateの実現にはWeakMapが使える。
簡単に書きたいからという理由だけのために貴重な記号を消費しないでほしい。rubyじゃあるまいし。

525 = :

JSを2050年以降まで延命させたいと言うのなら分かるが
そろそろ壮年期だと思えば消費しどころだろ

526 = :

どんどん仕様を追加していくとC++みたいになる
そして飽きられて次の言語へ・・・
とならないかな

527 = :

C++の場合もうすでに飽きられてる
Googleとか大手は必ず自分たちでC++をマクロなどで改造して使ってるし
そうで無い人はもうとっくに諦めてる
俺たちは安定と速度を求めて不便なC++を使ってるのだから
便利な機能なんて誰も求めてねーよとなってるだけ
もう誰からも進化を期待されない段階になる前に機能を追加していく必要がある

528 = :

無節操に一貫性なく機能を追加していったrubyはもはや誰からも期待されてないけどな。

529 = :

>>526
C++みたいな最強言語は一個あれば良い
それをラッパーして使う

530 = :

>>528
rubyどこで失敗したんだろうな
一時は使用者数ベスト5ぐらいには入ってなかったか

531 = :

>>526
C++の問題点はGCを搭載しなかったからで
そのせいでテンプレートの使用が実質必須になったから

532 = :

C++にガベコレ載せたらC++じゃないじゃん
住み分けだよ

533 = :

>>530
独善的な選民意識
ドキュメント軽視
ウィンドウズ蔑視

開発者がいくらMacやLinux使ってようが、ユーザーベースで8～9割はウィンドウズなわけよ。
今のPythonの利用シーンを見てみると、職業プログラマ以外が自分の仕事に活用するようなユースケースが多い。
こういうユースケースに、コミュニティのウィンドウズ蔑視は致命傷になったな。ドキュメント軽視も。そういう人たちは「コードが仕様だ！」とか言われてもハァ？だろうしな。
ま、Railsが沈むまでは生きてるよ。Railsのバッテリーとして。

534 = :

>>528,530
Rubyの敗因は開発側のリソース不足
公言したことが守れないのでコミュニティから見放された
でもJSのようにチートな企業がサポートしてないのでどうしようもない
まあ細々とやっていくことが必ずしも悪いことでは無いと思うが

539 = :

Rubyに親でもころされたんか

543 = :

いや、それくらい自分で調べろよ
調べて理解できないのならここで講義できるわけでもないしお前が分かるように伝えるすべがない

544 = :

あいーあじゃじゃした

545 = :

Nodeのほうがプリミティブ。
用がなきゃエレメント使っときゃいい。
テキストノードいじらざるを得ないことはあったが…

546 = :

ありがとう
一度調べてみます

549 = :

クラスとプロトタイプは対立する概念ではない
最初からクラスシステムが提供されていてそれに縛られるのがクラスベース言語
プロトタイプベース言語でも構造化のためにやっぱりクラスシステムは必要になる場合も多い
ただそれに縛られていないと言うだけ

550 = :

クラスベースのクラスしかクラスが無いと思いこんでるやつのほうがよっぽどクラスベースバカというオチか

前へ 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