コンテンツにスキップ

ノート:JavaScript

ページのコンテンツが他の言語でサポートされていません。

これはこのページの過去の版です。Oakw (会話 | 投稿記録) による 2007年12月17日 (月) 13:40個人設定で未設定ならUTC)時点の版 (privateメソッド、publicメソッドの実装方法の妥当性: コメントの充実...)であり、現在の版とは大きく異なる場合があります。


最新のコメント:17 年前 | トピック:privateメソッド、publicメソッドの実装方法の妥当性 | 投稿者:Oakw

読み

「ジャワスクリプト」という読みは存在するのでしょうか? とりあえず併記のままにしておきますが、ソースがあれば嬉しいです。-- iwaim 2006年6月30日 (金) 02:36 (UTC)返信

元々、SunのJava(ジャワ)が語源ですよね?ジャワ島、ジャワティー、ジャワカレー…、ジャバと読む方が困難かと思いますが。初期にはジャワと読まれていたと思います(これは私の周辺だけかもしれませんが)。

検索エンジンの結果を見ると「ジャバスクリプト」「ジャヴァ〃」「ジャワ〃」の順で少なくなりますね。ちなみに英語圏のプログラマーも「ジャヴァ〃」と発音しています。併記するならむしろ「ジャヴァ」の方が優先されるべきではないかと思うのですが…。
なるほど。JavaHouse:1342JavaHouse:1345あたりの話ですか。項式なソースがない限りは現在の順で併記しておきますかね。-- iwaim 2006年7月12日 (水) 17:12 (UTC)返信
vは現代の日本語にはない発音ですから、仕方ないですね。ちょっとした疑問ですが、一般名詞ではバイオリン、バナジウム、バレーボールのように「バ」、固有名詞ではモスクワ、ウラジオストク、フォルクスワーゲンのように「ワ」なんでしょうか。
前者は英語(っぽい)読みで、フォルクスワーゲンは単にドイツ語っぽい読み方ですね。ロシア語はよくわかりませんが別の話ではないでしょうか。「ジャワ」はフランス語(っぽい)読みのようです。私は「ジャバ」だけ書いてあればいいと思います。--こいつぅ 2006年7月14日 (金) 08:36 (UTC)返信
通常日本で「ジャワ…」と読む人はいないので削除しました。--CasinoKat 2007年3月1日 (木) 18:10 (UTC)返信

要望

Camel記法の説明がほしい。Crazy柔術 2005年7月9日 (土) 02:25 (UTC)返信

  • 同時に、Pascal記法やハンガリアン記法の記事も無さそうですね。それほど量も無いと思いますが、これらは一つのページにすべきでしょうか、それとも個別に作成すべきでしょうか? --ばあど 2007年1月4日 (木) 16:49 (UTC)返信

主な実装

消去されてしまったようですがなぜでしょう。SchemeでもSmalltalkでもPythonでも触れているように主要な実装系に言及があるのは自然だと思うのですが。--こいつぅ 2006年7月20日 (木) 15:37 (UTC)返信

要出典

すでに一般化的に周知の事実になっている事柄に対しても、「要出典」を求めすぎている気がします。おかげで「要出典」が多すぎで、読みづらい気がするのですが……。 例えば、

  • 「様々なアプリケーションで自動実行の用途におけるマクロ言語としても採用されている」
実際にAdobe AcrobatでJavaScriptがマクロとして実装されている。
  • 「Java言語と名前や文法が似ているためしばしば混同されるが、互換性は全くない」
どう考えても互換性があるとは思えない。
  • 「必要以上にアマチュアが使うもの低機能な言語と捉えられてしまうことになる」
http://d.hatena.ne.jp/brazil/20050829/1125321936
  • 「JavaScriptによる脆弱性や攻撃は存在しており、状況が本質的に変わった訳ではない」
JavaScriptの仕様の問題ではなく、実装の問題であるが(特にWindows)脆弱性は常に報告されているのでは……。
直接の出典元になり得るか分かりませんが、JavaScriptを悪用した攻撃手法--セキュリティ研究者らが発見:ニュース - CNET Japanなど、関連性の高い情報源と思われるのですがいかがでしょう?

明らかにおかしい所にも張ってあったので取り外しました。--Sha-1024 2007年5月7日 (月) 16:39 (UTC)返信

privateメソッド、publicメソッドの実装方法の妥当性

privateメソッド、publicメソッドの実装方法のサンプルですが, 単にそのように見えるテクニックであるだけで,JavaScriptの説明ではなく,誤っているように思います。 少なくとも現在の JavaScript 自体には private という概念はないわけですから,削除を提案します。--Oakw 2007年12月17日 (月) 13:02 (UTC)返信

説明
これらの仕組みは,コンストラクタ内(Test = function(){...} )の var で定義された変数が,同一コンストラクタ内で定義されたメソッドであるクロージャに束縛されているだけです。
この変数は同一コンストラクタ内で定義されたメソッドからのみ解決できます。外部からアクセスできないので private のように見えます。
しかし,のようにコンストラクタ外で定義したメソッドでは,同一インスタンスであってもアクセスできません。これは private を超えた厳しさです。
// 例
var word = "Here is outside..."; // グローバルでも用意

function Test() {
	var word = "Hello World!"; // * 問題の変数 *
 	this.getWord = function() { // アクセッサ..クロージャとしてwordを取り込む
 		return word;
	}
        this.setWord = function(v) { // アクセッサ..クロージャとしてwordを取り込む
                word = v;
        }
}
var t = new Test();
alert(t.getWord()); // "Hello World!" が見える

t.getWord2 = function(){ // Test.protorype.getWord2 =... でもだめ
	return word;
}
alert(t.getWord2()); // "Here is outside..." 問題の変数ではなくグローバル word が見える
より深刻なことに,クラスを継承した場合は,すべての子インスタンスで同一の変数(word)を参照することになります。
// 例のつづき
function TestChild() {}
TestChild.prototype = new Test();

var t2 = new TestChild();
var t3 = new TestChild();
t2.setWord("Goodbye World!");
alert(t3.getWord()); // いじっていない「はず」の t3 が "Goodbye World!" を返す。
これでは継承が使い物にならなくなり,オブジェクト指向として致命的です。