Javascriptらしいprototype継承ってことかね
Javascriptでオブジェクト指向やろうって方向性とは合わない気がするけど

Prototypal Inheritance in JavaScript
http://javascript.crockford.com/prototypal.html

var a = {};
a.name = "test";
a.f = {};
a.f.show = function(){console.log(this.name);};
console.log(a.f.show());

testが表示されません何故ですか？

>>953
それを言い始めるとその関数が(O: Object, Properties?: Object) => Objectであることも確かめないと
JSONの例もそう >>908,909
Objectかどうか、functionかどうか、それでは範囲が広すぎる
中途半端なことをするくらいなら簡潔な !Object.create でいい
Object.createに期待していない値が代入されることを想定するのは、
undefinedに値が代入されることを想定するようなもの
行儀の悪いコードを想定して自分のコードを複雑化させるのは悪手

>>955
a.f.show()として呼び出すとその関数内のthisはa.fになる
a.f.show.call(a)と呼び出すか、関数内で直接aを参照するか、a.fにaへの参照を持たせる
a.f = {parent: a};
a.f.show = function(){console.log(this.parent.name);};

般　僧 掲 若 咒 咒 菩 波 夢 罫 依 智 老 識 色 無 垢 舎 空 利 時 観 　摩
若　掲 諦 波 能 是 提 羅 想 礙 般 亦 死 界 声 受 不 利 空 子 照 自　 訶
心　諦 　　羅 除 大 故 蜜 究 故 若 無 亦 無 香 想 浄 子 即 色 見 在 　般
経　　　掲 蜜 一 明 知 多 竟 無 波 得 無 無 味 行 不 是 是 不 五 菩　 若
　 　菩 諦 多 切 咒 般 故 涅 有 羅 以 老 明 觸 識 増 諸 色 異 蘊 薩　 波
　　 提 　　咒 苦 是 若 得 槃 恐 蜜 無 死 亦 法 無 不 法 受 空 皆 行　 羅
　 　薩 波 即 真 無 波 阿 三 怖 多 所 尽 無 無 眼 減 空 想 空 空 深　 蜜
　　 婆 羅 説 実 上 羅 耨 世 遠 故 得 無 無 眼 耳 是 相 行 不 度 般　 多
　　 訶 掲 咒 不 咒 蜜 多 諸 離 心 故 苦 明 界 鼻 故 不 識 異 一 若　 心
　　　　 諦 曰 虚 是 多 羅 佛 一 無 菩 集 尽 乃 舌 空 生 亦 色 切 波　 経
　　　　　　　　 故 無 是 三 依 切 罫 提 滅 乃 至 身 中 不 復 色 苦 羅
　　　　 波　　 説 等 大 藐 般 顛 礙 薩 道 至 無 意 無 滅 如 即 厄 蜜
　　　 　羅　　 般 等 神 三 若 倒 無 侘 無 無 意 無 色 不 是 是 舎 多

>>950
めっちゃわかりやすくありがとうございます
ようするにそんなに拘る必要もないよってことですね

>>948
それはただの二流の連中だろ
仕様には哲学は書いてねーんだよ

>>950
さすがクロックフォードもS級技術者の端くれだな

朝方までアホな質問してたニートが目を覚ましたか

>>944の件ですが、
jsbinでテストしてみたところ、すぐに反映しました
ということは、
スクリプトが設定した値とは違う値が入る可能性もある、
ということになると思います。
おそらくほとんどのスクリプトは
別ウインドウでのクッキー変更の可能性を考慮していないと思いますが、
考慮してる人いますか？

>>950
undefinedチェックがナンセンスなら
そもそもこんな議論も発生しないだろw
別に2chだけで起きてるわけじゃないぞ
実際にあり得るし現にあることをナンセンスと言う方がナンセンス

>>953
明らかに callbable なのだから function 判定するのがより安全なのは確かだと思う。
様々な状況を想定して例外を考えるのはより良いプログラムを書くことに繋がる。

> 行儀の悪いコードを想定して自分のコードを複雑化させるのは悪手
思想の違いとしか思えないけど。
行儀の悪い状況も想定して回避できるリスクは回避するのが私のスタンス。
あなたは(あなたにとって)ありえない状況は考慮せず、安全よりもシンプルを追求してる。
(最も、「ありえない状況」は主観的なものだから人によって異なるだろう。私にとってはこれはありえない状況ではない。)
安全とシンプルはトレードオフの関係にある。

思想の違いで議論を始めても水掛け論になるのは目に見えてる。
唯一解のない議論を始めても仕方ないかと。

何度も呼び出す場合はAとBどっちがいいですか？

A
var obj = {function test(){}};
obj.test();
B
var obj = function(){}
obj.prototype.test = function(){};
obj.test();

>>967
A は SyntaxError: Unexpected identifier

>>967
B は TypeError: undefined is not a function だった
ちゃんとテストしてから質問するように

思想の違いとか宗教論争とか言って己の二流性を直視できない奴がいるな
技術の進化は技術者が思想に関する論争を戦わせた結果なんだよ
個人の好みに帰されることを一流の技術者が熱論するわけねーだろ
二流の欠点は一流を理解できず、
自分を誤魔化す理由の捏造に逃げてしまうところ

>>966 は >>956 宛だった。

A
var test = {};
test.a = function(){};
test.a();
B
function test(){}
test.prototype.a = function(){}
var t = new test();
t.a();

少数が書き込みを繰り返しているんだろうけど、「一流技術者」とか「Ａ級」とか「議論しているから問題があるはずだ」とか主観的な物言いが目立つね

思想の違いを認識してない代表が>>766みたいな奴だな
OOPの作法に従って書いてある本を手にとってトンチンカンな事で文句付ける

>>969
>>972

>>966
[1] Object.create = "create";
[2] Object.create = function() {return {};};
あなたにとって[1]はあり得て[2]はあり得ないわけだ
俺には分からんね
どっちも相手にしない それだけだ

>>975
AはBよりパフォーマンスが高いが、複数のインスタンスを生成できない
BはAよりパフォーマンスが低いが、複数のインスタンスを生成できる
用途に合った機能を使え

>>976
[1], [2] 共にありうるが、[2] は回避手段を私が知らないので諦めている。
何か有効な対策があるなら教えて欲しい。

リスクはゼロには出来ないが、出来るだけ軽減させるものだ。
[1] のリスクだけでも回避できるなら回避した方が良いと私は考える。
「リスクをゼロに出来ないからノーガード戦法をとる」も一つの意見なのだろうけど、ちょっと私には賛同しがたいかな。

>>973
主観的じゃないものいいってなんだよ
仮にそんなものがあるとして、そんなものには価値はない
すでにあるものについて語ってるだけだからgoogleさえあればお前はいらない

>>956
>行儀の悪いコードを想定して自分のコードを複雑化させるのは悪手

これは重要なことだな
時が経てば自動的になくなっていく瑕疵のために今あるコードを醜くするのは悪手
その醜さがいずれ腐敗しだすのだから

var A = {};
A.a = function(){
A.b();
};
これb()がないのにjshintでエラー出ません
どうしてですか？

>>979
主観と客観の違いってわかる？
技術者なら客観的事実に基づいた論理で議論すべきだよ
事実の根拠となる情報源は確度が高いこと(例えば、ES, DOM仕様書など)が前提としてあるけどね
後は比較コードを示して、どちらがより良いか論理的に説明して見せるとか

>>981
呼び出されてないから

間違えた、jshintか
jshintは知らんが、呼び出せばコンソールで「TypeError: undefined is not a function」になる
jshintの前にコンソールを見るべきだ
jshintの設計思想なんて作者以外知りようがない

このスレを見ていても分かるよな
A級以上の技術者の視点は未来にあり、「あるべき姿」について語る
B級以下の技術者の視点は過去と現在にあり、「今ある姿」についてしか語ることができない
そして今は存在しないものについての言葉を、
「主観的」「宗教論争」「思想の違い」などの言葉押し込めて自分を安心させる
「仕様」という言葉を好むのもB級の特徴

ようＣ級

>>978
>=IE8のためにNodeのPolyfillを作るとしたらどう書く？
<=IE9ではobjectだが、他のブラウザはfunctionで定義されてる
if(!("Node"in window)&&typeof Node!=="object"&&typeof Node!=="function")
長ったらしい

間違えた
if(!(("Node"in window)&&typeof Node==="object")||typeof Node==="function"))
　Node =

これで十分だろう
if(!window.Node)
　Node =

まぁほとんどの雇われ技術者にとって重要なことは
「誰かが考えたことをどうやってやるか」でしかないから
B級で十分なんだろうけどね。
しかし彼らの硬直化した思考からは
彼らが自分で考えるという行為をどれだけ奪われてきたのかに思いを致さざるをえず、
そのことに危機感を覚えるのである

>>987
> >=IE8のためにNodeのPolyfillを作るとしたらどう書く？
引用文を捏造するとは…
この人は誰と戦ってるんだろうか？

すまんな 大なり小なりも間違えてるな
一行目はie8以前、二行目はie9以降ってことだ
しかも("Node"in window)じゃなくて(window.Node)だな
寝るわ

>>991
いやそういうことではなくて…
>>978は「IE8のためにNodeのPolyfillを作るとしたらどう書く？」を質問してないでしょ
あなたが勝手に捏造しただけ

Object.createの思想とは何か？
考えるに、オブジェクト自身に産出の機能を持たせる、ということに他ならない
JavaScriptはもともと可能態（デュナミス）としてそのような形態を最初から孕んでいた
それを実現してやろうというのがS級技術者ダグラス・クロックフォードの発想である
別に本人に聞いたわけじゃないがそのように推察する
しかしこうすると、インスタンスという概念が消えてしまう
インスタンス自身も親になれるのだから。
とはいえ、普通はインスタンスを親にすることはないだろう。
産出するオブジェクトと、産出しないオブジェクトを、頭文字のcaseで判断することになるだろう
それは果たして美しいのか？という問題はある

スクリプトを呼び出す前に上書きされてるかも知れないから
console = 1
typeof console === undefined
typeof console === "undefined"
typeof console === void 0
どれもダメ
ちゃんとwindow.console === undefined && window.console.log === "function"
と確認するべき

ショートコーダーが大好きな jQuery も isFunction, isArraylike, isArray ...etc
判定の為の関数を多数定義してるんだよね
必要ならコードが長かろうが判定させる
それが基本

1000

誰か次スレたてられる？

1000