何がしたいのか，単純に「標準のOOP」がしたいなら，actionScriptを楽しんでいいのでは？
iPhoneから送信 2012/11/11 2:40、hiroqn <[email protected]> のメッセージ: > 初めての書き込みをさせていただく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を組織が安定的に供給していくことが望ましいのでは？。 > > という自分の意見です。 > > ここまで読んでいただき有り難うがざいます。 > 複数の内一つでも良いのでご意見お待ちしております。 > -- > > > --
