のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,934人
昨日:no data人
今日:
最近の注目
人気の最安値情報

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

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    101 = :

    式と宣言があるfunctionと違いアロー関数は式のみで宣言はない。
    巻き上げにfunction式とアロー関数式に違いはない。
    注意すべきはthisのみで、巻き上げに云々は関係ない。(var f = function(){};もvar f = () => {};も同じ)

    104 = :

    >>101
    なんで宣言を省いてしまうのか

    105 = :

    そこは考え方や範囲の違いだから深く突っ込まなくていいよ
    どうせ分かり会うことはないだろうから

    106 = :

    functionをアロー関数にするのだから当然宣言も含まれる
    考え方以前の問題だろ

    107 = :

    アロー関数の趣旨は無名関数を簡単に書けるようにすること。
    で、無名関数はfunctionでも式としてしか書けない(() => {}に対してfunction(){})
    嘘だと思うなら>>106はfunction(){}を宣言文で書いてみろよw
    function f(){}は有効な関数宣言だけど
    function(){}はすぐGC対象になる関数式だぞw

    108 = :

    (駄目だこいつ質問の意図を理解してねぇ

    109 = :

    >>108
    だから突っ込むなと言っただろ
    こうなることは分かりきったことだから
    お前こそ人の発言の意図を理解しろ

    110 = :

    >>107>>77と同タイプでマウント君
    建設的な議論は望めない

    111 = :

    >>110

    > ・他人の回答を批判する代わりに、自分ならこう書くという例を示してください

    112 = :

    ネストした関数内のthis は、グローバルを指してしまうから、よくバグルだろ

    アロー関数の方が、this が、jQuery, Haxe みたいに正常に動くから、
    this を一々、自分で、self, that に、代入しなくてもよいw

    >>96
    Linux なら、ps コマンドなどで、システムの状態を調べる

    Windows のPowerShell にも、そういうコマンドがあるのでは?

    115 = :

    プロトタイプ(__proto__)の仕組みは、自分が預かり知らないことを
    全てプロトタイプ先に任すというものなので継承ではなく委譲
    prototypeプロパティは委譲させられるものを定義する場所で
    それをプロトタイプとしたオブジェクトを生み出すnew演算子の効果を持って
    形として継承がさせているように見える

    116 = :

    継承でも委譲でもなく、参照が連鎖するだけ

    117 = :

    >>115
    その継承と委譲の区別意味あるか?

    120 = :

    > 全てプロトタイプ先に任すというものなので継承ではなく委譲

    全くしっくり来ないわ
    jQuery#proxyでも委譲云々を唱える奴がいたが、ただの宗教論にしか聞こえない

    121 = :

    なんでそこでjQuery#proxyがでてくるのかわからん

    継承は親クラスから機能を受け継ぐもので
    委譲は処理を別のものにさせるものってだけじゃないか

    その実装がどうなってるかは関係ないし、
    継承、委譲の考え方に、それらを実現するときに使う道具も関係ない

    122 = :

    簡単に考えれば分かることなのにね

    123 = :

    >>121
    proxyは過去いってた奴がいただけで俺も賛同してない

    124 = :

    賛同するかしないかじゃなくて、
    今の話に関係ない話だろってこと

    125 = :

    >>121
    > 継承は親クラスから機能を受け継ぐもので

    はいダウト。「親クラスから機能を受け継ぐ」というのはのはクラスベースオブジェクト指向固有の考え方。

    > その実装がどうなってるかは関係ないし、

    と自分で書いてるのに語るに落ちたなw

    126 = :

    通常のプロパティアクセスも出来るのに「委譲」になるわけがない

    127 = :

    > 「親クラスから機能を受け継ぐ」というのはのはクラスベースオブジェクト指向固有の考え方。

    これが間違い。プロトタイプベースでも「親クラスから機能を受け継ぐ」ことは継承になる。
    これは概念の話なので、言語としてクラスとして読んでいるかどうかは関係ない。
    クラスに相当するものがあって、それを引き継ぐならどんな実装でも継承

    128 = :

    >>115
    > 全てプロトタイプ先に任すというものなので継承ではなく委譲

    全てを任せてないだろ

    129 = :

    >>127
    「クラスに相当するもの」というのがクラスベース脳から見たらそう見えるというだけ。
    頭がクラスベースの実装に染まってるからお前はもうバイアスなしにモノを見ることは無理。

    130 = :

    >>129
    だから継承はクラスベースのクラス相当のものための用語なんだが?
    継承=クラスベースなんだよ

    正確に言えばプロトタイプベースでもクラスは作れるが、以前のJavaScriptは
    独特のルールを守って実装しなければいけないから面倒だった。
    このJavaScriptでクラスが作りづらいというのはJavaScriptの制限であって
    プロトタイプベースの制限ではない

    その証拠に最近(といっても随分前だが)改善されてJavaScriptでもクラスを作ることが用意になった。

    で、以前の面倒な実装でも今の簡単な実装でも、実装がどうであれ「クラス」にすぎない。
    クラスに相当するものは、クラスベースでもプロトタイプベースでも(それ以外)でも存在する。

    プロトタイプベースだからクラスがないと考えるのは、お前が持ってるバイアスにすぎない。

    131 = :

    わざわざ質問してきてこうなんだよと教えたら、いやそうじゃないはずだと突っ張るやつってなんなんだろう

    132 = :

    残念ながら、回答にケチつけて、マウントとるのか大好き勢が常駐してるんだよ

    133 = :

    何が制限だバカバカしい。クラスの存在を前提としないプロトタイプベースのオブジェクト指向でクラスが作りにくくて何が悪い。
    スポーツカーつかまえてでもそれ農道走りにくいよね言うてるのと同じじゃボケ

    134 = :

    JSではクラスは作りやすいでしょ
    class構文入ってるんだから

    135 = :

    クラス構文はおじいちゃん介護構文

    137 = :

    >>134
    それな。プロタイプベースってのは内部の実装に過ぎず
    class構文を使えば、プロタイプベースでクラスを容易に実装できる。

    昔はclass構文がなかったから、クラスを実装するのは容易ではなかったが
    別に実装できなかったわけじゃない。

    138 = :

    ECMAScript 2015 で導入された JavaScript クラスは、JavaScript にすでにあるプロトタイプベース継承の糖衣構文です。クラス構文は、新しいオブジェクト指向継承モデルを JavaScript に導入しているわけではありません。

    おととい来てね、おじいちゃん?ww

    139 = :

    >>138
    糖衣構文だから、どういうこと?

    最初から糖衣構文を使うことで、プロタイプベースでも
    クラスが書きやすくなったって話をしてるよね?

    140 = :

    >>137
    > それな。プロタイプベースってのは内部の実装に過ぎず

    仕様を無視した、プロトタイプベースじゃないJavaScript実装が存在するの?

    141 = :

    「Cでもクラス相当のものは実装できるからCにクラスはある!」
    「CでもGC相当のものは実装できるからCはGC言語と言える!」

    142 = :

    実装すればあるだろうけど実装してないものにはないというだけ

    144 = :

    文言は細かく見よう

    >>137
    > それな。「プロタイプベース」ってのは内部の実装に過ぎず

    >>139
    > 最初から糖衣構文を使うことで、「プロタイプベース」でも

    「プロトタイプベース」ではなく、「プロタイプベース」と書いてる(バグリング君も似たようなことをしたな)
    仕様を知らないので、「内部の実装」と知ったかぶりをする

    145 = :

    うん実装じゃなくて仕様だよねw

    146 = :

    クラスベースっていうのはクラスから逃れられない言語ということであって、
    民主主義国家でなくても民主主義はあるしできるように、
    JSでも当然クラスという概念は持ち出せるし、構文にまでなってるんだから、
    JSにクラスというものは当然に存在すると考えるのが合理的

    147 = :

    つまりC言語にもクラスは当然存在する。実装できるからw

    148 = :

    クラスを実装していないC言語にクラスは存在しない。あたりまえ。

    149 = :

    C++はCで実装されたんだからクラスを存在せしめたのはC言語。あたりまえ。

    150 = :

    >>147
    クラスというのは概念なので
    クラス専用の構文がないC言語でも
    クラスの概念を導入したコードを書ける。

    というのが正しいかな


    以前のJavaScriptでもクラスの概念を導入することは可能だったし
    newがあるんだから、クラスの概念を使うのが普通だった。

    それに加えて最近のJavaScriptではクラス専用の構文が加わり
    クラスを導入したコードが簡単にかけるようになった。


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について