たしかに今回の考えは生成物としてのコードの構造といった点からしか考えておりませんでした。 npmの仕組み及び実行時の処理コストという点から考えた意見は非常に参考になりました。
なので、そういったもの(Issac氏がかなり否定的な意見をお持ちですが)を実現する上では、 標準moduleもしくはそれに準ずるものでなければならないのですかね・・・ 2012年11月12日月曜日 12時57分58秒 UTC+9 aki_mana: > > 眞鍋です > > Node の話だとして、 > > > #疑問 - npmに上がっている多くのなmoduleがそういったPackageに依存していないのはなぜか > の回答になれば良いのですが、 > > 私自身、npm のパッケージ管理は特殊だなぁと感じた一人です。 > > 何が特殊か？というと２点ほど。 > １）他の言語のような、名前空間で管理されたパッケージ＆名前空間に対応したディレクトリ配備ではないということ。 > ２）各モジュールに上位互換を強制しないスタイル。 > > バージョンの絡みもあって、条件に合わない場合は、配備したモジュールのディレクトリに node_modules/ > を掘り下げて、対応した新しいバージョンの同名モジュールを置くのも、npm の独特な挙動。 > > もし、上位互換を強制すると、「他言語のようにパッケージ管理も容易に可能だし、利用者も簡単に導入できそう」となるのですが、読み込むモジュールはJavaScriptそのものなので、サーバー上で走る > > > V8エンジンにとって、メモリ消費に直結する。上位互換を意識すると処理コストばかり上がる。 > > 「node の場合、上位互換の補償された安易な package化はしない。というか、敢えて避けている」と感じます。 > > > > 2012年11月11日 9:56 gpgkd906 <[email protected] <javascript:>>: > > 何がしたいのか，単純に「標準のOOP」がしたいなら，actionScriptを楽しんでいいのでは？ > > > > iPhoneから送信 > > > > 2012/11/11 2:40、hiroqn <[email protected] <javascript:>> のメッセージ: > > > > 初めての書き込みをさせていただくhiroqnと申します。 > > > > Nodeにおいてという表現は限定した言い方でで、 > > 実際はCommonJSのModuleがありES5が互換性を考えずに使うことができる状況に関してです。 > > > > 本家のnodejs Googleグループでも議論されていたこと（以下のリンク）なのですが、 > > 実際にNode環境でオブジェクト指向プログラミングをしていく上で質問,提案,疑問があり、意見が欲しいです。 > > Simple LightWeight OOP. 100% compatibility with JavaScript > > > > まず、前提としていくつか。 > > jsの標準的な機能としてプロトタイプベースのOOPが提供されていると思います。 > > 関数オブジェクトのprototypeプロパティを拡張していく方法でメソッドを定義していき、 > > プロトタイプチェーンをつかって継承を実践していくことです。 > > それは以下のようなコードになると思います。 > > > > function Base(){} > > Base.prototype.t = function(){}; > > function Sub(){} > > //下の部分は実質util.inherits(Base,Sub); > > Sub.prototype = Object.create(Base.prototype, { > > constructor: { > > value: Sub, > > enumerable: false, > > writable: true, > > configurable: true > > } > > }); > > > > Sub.prototype.t2 = function(){}; > > > > > > > > 今回、このようなオブジェクトの状態をこのトピックのjsにおける標準的なOOPとした上で進めたいと思います。 > > 追記ですがmixinも標準的なOOPな気はするので、それもとりあえず含めます。 > > > > 上記のリンクにあるコードは(https://gist.github.com/3990372)は*標準的なOOP*の文字量を減らすというものです。 > > > 残念ながら今回提示されていたコードは目新しいわけではなく、 > > 数多くのライブラリの中で似たようなものを見つけることができます。 > > しかし、今回の自分の投稿はそれを否定するわけではなく、 > > このようなコードをつかっていくことは良いものと考えています。 > > その上でいくつかの疑問、意見があります。 > > > > 本家のIssueでは否定的な意見が多いようです。 > > > > #質問 - このようなものをpackage化し依存するべきではないのでしょうか？ > > > > 依存しない場合には、 > > * 原始的なprototypeを`Kls.prototype.method`が並ぶようなコードを書く。それはすこし冗長に思いますが。 > > * 各ユーザーが自分がやりやすいような*標準的なOOP*の記述を助けるmoduleを書き、それを使う（これは何度か見たことがあります）。 > > * CoffeeScriptのようなものを使うという選択肢はこれに入るのではと思います。 > > > > 仮に依存していく場合、OOPをたすけるパッケージの規模の大きさを3種類程度に分けることができます。 > > 1. *標準的なOOP*な記述を助け、いくつかのヘルプを含んだもの。 > > 2. よりクラスベースのOOPに近づけた書き方や多言語風の書き方をサポートし、 > > コーディング上便利なメソッドが追加されたもの。 > > 3. 利便性を追求し、*標準的なOOP*から離れていったもの。 > > > > 順にLv.1、Lv.2、Lv.3としておき、例を上げていきます。 > > > > util.inheritsもLv.1の一つと捉えることができると思います。 > > ded/klassやprototype.jsはLv.1もしくは軽いLv.2と考えれます。 > > Jooseはやや重めのLv.2でしょうか。 > > Lv.2にあたるライブラリは多いのでそれなりにイケてると思うものも省きます。 > > JS.ClassやBackbone.ModelなどはLv.3の一つと考えることができます。 > > > > Lv.2に分類することができるライブラリはプロジェクトの向き不向きがあり、考えて使えば役に立つと思います。 > > しかし、Lv.1に分類できるようなものが仮に依存するなら最終的に多く使われるように思います。 > > > > #提案もしくは希望 - Lv.1のものは安心して依存していく上で個人より団体が管理するべきではないでしょうか？ > > 具体的にはある程度大きな組織(nodejs_jpなど)が広くコードを募り厳選し管理することです。 > > > > #疑問 - 将来的に標準moduleとして取り入れられることはあるのでしょうか。 > > そういったものとしてutil.inheritsだけなは不足しているように思います。 > > (util._extendという使っていいのかよくわからないものもありますが) > > > > また、感想ですがそういったLv.1が追加Packageを使うことでLv.2にするようなPackageはイケてるように思います。 > > > > > > #疑問 - npmに上がっている多くのなmoduleがそういったPackageに依存していないのはなぜか > > > > 長々と書かせていただきましたが、まとめると > > > > *標準的なOOP*を助けるPackageを組織が安定的に供給していくことが望ましいのでは？。 > > > > という自分の意見です。 > > > > ここまで読んでいただき有り難うがざいます。 > > 複数の内一つでも良いのでご意見お待ちしております。 > > > > -- > > > > > > > > > > -- > > > > > > > --
