トーク:JavaScript
話題追加ページ名の区切りについて
[編集]書名とページ名の区切りを ":" にしておられますが、これは名前空間の接頭辞と紛らわしいので控えていただいたほうが宜しいかと思いますが如何でしょうか(なお、英語版の命名規則に似たような形式が例に挙げられていますが、それに照らすとあちらでは ":" のあとに半角空白が挿入されているという違いが見られるようです)。これについて皆様のご意見を伺いたいのですが、宜しいでしょうか(Wikibooks‐ノート:ページ名の付け方にご意見を頂けると幸いです)。--Lots 2005年1月25日 (火) 07:12 (UTC)
再編案
[編集]C言語の教科書の方でも再編計画が進んでいますが、HTML5/ECMAScript 5時代の幕開けに際して、日本語版、英語版、Core JavaScript 1.5 Reference - MDCともに内容がいささか古くなっていることが否めません。そこで、本教科書の再編案を提出します。
現状の問題点
[編集]- 解説が回りくどい
- 言語仕様を列挙したリファレンスが貧弱
- サブページ化されておらず大量の不動産を占有している
改善策
[編集]- リファレンスを柱としながらも仕様書のように小難しくなく、わかりやすい実状に即した率直な解説を付けることにより、リファレンスと解説を統合する。
- JavaScript以下にすべてのページを建設し、全面サブページ化を実現する。
- リファレンスと入門書で二重に解説する手間が省け、サブページを追加すればよいので仕様の変更に強くなります。
目次案
[編集]- JavaScript
- JavaScript/Array
- JavaScript/Boolean
- JavaScript/Date
- JavaScript/Error
- JavaScript/EvalError
- JavaScript/Function
- JavaScript/Math
- JavaScript/Number
- JavaScript/Object
- JavaScript/RangeError
- JavaScript/ReferenceError
- JavaScript/RegExp
- JavaScript/String
- JavaScript/SyntaxError
- JavaScript/TypeError
- JavaScript/URIError
これらの標準グローバルオブジェクトを中心に、これらのページのサブページとしてすべてのプロパティ・メソッドを網羅します。たとえばJavaScript/String以下は、
このようになります。現在JavaScript 標準ライブラリ Globalで解説されているグローバル関数および3つのグローバルプロパティ(NaN、Infinity、およびundefined)は、グローバルオブジェクトとは別にページを設けます。
- JavaScript/decodeURI
- JavaScript/decodeURIComponent
- JavaScript/encodeURI
- JavaScript/encodeURIComponent
- JavaScript/eval
- (中略)
- JavaScript/Infinity
- JavaScript/NaN
- JavaScript/undefined
演算子や文、予約語、それにコメントなどの解説も別にページを設けます。
- JavaScript/演算子
- JavaScript/算術演算子
- JavaScript/代入演算子
- JavaScript/ビット演算子
- (中略)
- JavaScript/delete
- JavaScript/function
- JavaScript/in
- (中略)
- JavaScript/コンマ演算子
- JavaScript/演算子の優先順位(付録; またはJavaScript/演算子に統合)
- JavaScript/変数
- JavaScript/var
- JavaScript/const
- JavaScript/let
- JavaScript/文
- JavaScript/ブロック
- JavaScript/break
- JavaScript/continue
- JavaScript/if-else
- JavaScript/for
- JavaScript/while
- (...など)
これらのページはリファレンスでもありますが、解説・入門の性質が強いので、JavaScript/演算子/算術演算子やJavaScript/文/if-elseのように過度なサブページ化は控えた方がよいでしょう。
そのほかRegExp.lastIndexやRegExp.multilineなど、仕様にあるプロパティやメソッドなどはサブページ化し、それ以外のもの、たとえば正規表現の文法の解説などは別にページを設けるという柔軟な考え方でやっていきたいと思います。
反対意見が出なければ来月より施行したいと思います。以上、ご検討よろしくお願いします。--Yuki Konno 2010年3月23日 (火) 07:02 (UTC)
どうも、ご意見を聞く限り このテキストは、言語仕様のリファレンスとして使われがちなのだと思いますが C言語の聖典のK&R等も、文法を区分けして解説する事に重点を置いていたので 文法周辺の解説はやはり最初のほうに必要なのではないでしょうか?
- JavaScript復習、あたりを整理縮小
- 発展編以降を大幅に拡充
このあたりでバランスを取ったほうが良い様にに見えます—以上の署名の無いコメントは、Baban(会話・履歴)さんが 2010-03-28T20:34:44 (UTC) に投稿したものです(Yuki Konnoによる附記)。
もちろんJavaScriptをまったく知らない読者を想定して書かれている教科書ですから、基本的な文法の解説を最初に持ってくるのが妥当だと思います。目次案と書いたのは目次の一部を抜き出したもので、いきなりJavaScript/Arrayから始まるという意図ではありませんでした。
いずれにせよ、ページとしては独立させて目次の並べ方を工夫するというやり方ではどうでしょうか。むしろ現状ではリファレンスが貧弱なので、リファレンスをあまりにも強調しすぎてしまいました。たしかに解説を見失っていました。
このような出だしではいかがでしょうか。配列のリンクをJavaScript/Arrayにし、Arrayオブジェクトの解説と配列の解説を一緒にする、というのが私の考えです。つまり入門編と発展編を統合するような形です。Arrayオブジェクトの個々のメソッドはさらにサブページ化して解説します。配列操作の解説でArrayオブジェクトのさわりも紹介できるので便利ではないでしょうか。英語版を参考にしました。--Yuki Konno 2010年3月29日 (月) 04:06 (UTC)
入門編と発展編を統合案ということで私は賛成です、あとは発展編部分の解説をどれくらい入門に組み込んで、リファレンス部分にどれだけ持っていくかですが 編集する個々人の裁量に任せて大丈夫なのでしょう。 問題がおきそうになったら、その都度刷り合わせていけるよう努力しましょう --Baban 2010年3月30日 (火) 03:49 (UTC)
上で「正規表現の文法の解説などは別にページを設ける」と言いましたが、やはりJavaScript/RegExpに統合したいと思います。
トップページに持っていくことを考慮し、完全な目次案を作ってみました。とはいえ未完成なので、適宜アップデートしていただけると幸いです。プロパティ・メソッドの列挙は実際は各オブジェクトのページで行う予定です。--Yuki Konno 2010年4月2日 (金) 03:52 (UTC)
- 素晴らしいですね。全体の構成(あらすじ)には私も異論ありません。これぐらい充実すれば、確かに入門用から、熟練者のリファレンスまで、幅広い学びに使えそうですね。ただ、メソッドひとつに1ページ、プロパティひとつに1ページというのは少々ページの分け方が細か過ぎないでしょうか。あまり細かく分けると、読むにも書くにも直すにも大変です。大雑把な目安のひとつとして、講義ひとこま分を1ページとする、という考え方があったかと思います。まずは1クラスを1ページぐらいにしては如何でしょうか。加筆が進んでページが長大になってきたときに分割を考えれば宜しいかと思います。
- また、正規表現など、 JavaScript 固有でなく様々な処理系に共通の要素は、あえて別ページにしたり、あえてサブページ体系から外す(別冊化する)のも手ですね。そうすれば、複数の教材で共有することができますから。先に述べたように、当初は RegExp オブジェクトの説明の一環として正規表現を説明しておき、後で分割や別冊化を考えるのも手です。 --Kanjy 2010年4月2日 (金) 10:27 (UTC)
- たしかに個々のメソッドに1ページ割くというのはやり過ぎだったかもしれません。おそらく現在最も充実しているであろうMDCのリファレンスを参考にしたものでしたが、とりあえず浅いところから加筆していく必要がありますね。個々のメソッドを丸暗記する人は少ないでしょうから、主に検索エンジン経由でのリファレンスとしての使われ方を想定すると、最終的にはメソッドごとに独立させた方が利便性が上がるのではないでしょうか。
- 正規表現の教科書はPerlの方が詳しいだけでなく、多くのプログラミング言語における事実上の標準でもあるので、そちらに任せちゃうのも一つの手ですね。正規表現自体は小さいのですが、非正規表現まで含めると煩雑になりがちなので。--Yuki Konno 2010年4月2日 (金) 15:46 (UTC)
- 今の段階では他に力を入れるべき要素があると思いますが、PerlにあってJavaScriptに無い機能が結構あるので、最終的には分離をした方が良いかと
--Baban 2010年4月5日 (月) 03:24 (UTC)
あと、関数とオブジェクトに関しては、無明関数以外にも、クロージャー等、CやJavaから来た人には 独特の要素が多くあるので項目の分離は許して欲しいところです。 --Baban 2010年4月5日 (月) 03:24 (UTC)
完全な目次案
[編集]JavaScriptに転記しました。--Yuki Konno 2010年4月6日 (火) 16:02 (UTC)
改名依頼
[編集]JavascriptをJsに改名する依頼
理由 ファイルでは、jsという拡張子を使っていて、Google検索でも、約 773,000,000 件 の検索結果だったからです。--HIROTO2 (トーク) 2020年6月18日 (木) 05:56 (UTC)
- (反対) JavaScriptの拡張子はjsですが、なぜ拡張子名に修正する必要があるのでしょうか。同様の論理であればMicrosoft Excelもxlsとかxlsxとかに改名すべきということになると思いますが、こんな変更をしたらかえって混乱を及ぼすと思います。また、基本的にページ名は正式名称が優先されるかと思いますが、Jsという略称が正式名称よりも広く知られているとかでもなさそうですし、改名することでかえってわかりにくくなると思います。さらに、こちらでJavaScriptでGoogle検索すると約 3,460,000,000 件 であり、むしろJsよりも件数が多いです。何のために改名が必要とされるのかよくわかりません。--郊外生活 (トーク) 2020年6月18日 (木) 09:08 (UTC)
- 反対まず、拡張子を名前にすると分かりずらくなります。せめてリダイレクトでしょう。もし拡張子名にすることで何かしらがもたらされるなら、それを説明しコミュニティの合意を形成された上で、WB:NCあたりに明記していただくか、ウィキプロジェクトでも作っていただきそちらでルール化してください。
- 2つ目。jawpに比べれば小規模なWMPですが、侮られぬよう。こちらにもテンプレート:Kaimeiがありますので、過去の事例を確認いただき、貼りつけ願います。「郷に入っては郷に従え」という言葉の通りです。--Darfre (Talk)2020年6月18日 (木) 09:51 (UTC)