Perl初心者の部屋： モジュールリスト 序章 第２章 第３章 第４章
第１章 − モジュール：創作、利用そして乱用
============================================
1) Perl 5 モジュール用語集
3) Perl 4 ライブラリースクリプトをモジュールへ変換するためのガイドライン
モジュールは、（.pmなしの）同名のクラスを（慣習として）提供する ファイルです。加えて、エクスポートされたシンポルをフェッチするのに callすることができる、そのクラスのインポートメソッドを提供します。 このモジュールは、動的 C または C++ オブジェクトをロードすること によって、そのメソッドのいくつかを実装するかもしれませんが、 それはモジュールの利用者に対して全体的に透過的であるべきです。 同様に、モジュールは、要求時にサプルーチン定義をslurp するための AUTOLOAD関数を用意しているかもしれませんが、これもまた透過的です。 存在するには、.pmファイルのみが要求されます。
A module is a file that (by convention) provides a class of the same name (sans the .pm), plus an import method in that class that can be called to fetch exported symbols. This module may implement some of its methods by loading dynamic C or C++ objects, but that should be totally transparent to the user of the module. Likewise, the module might set up an AUTOLOAD function to slurp in subroutine definitions on demand, but this is also transparent. Only the .pm file is required to exist.
もしそうなら、現存するモジュールを丸ごと、あるいは便利な特徴を 新しいクラスに継承して再利用してしまいましょう。それがうまく いかないようなら、現存するモジュールの機能を拡張したり高める 作業を行っているそのモジュールの著者とうまく折り合いをつけてみましょう。 完璧なサンプルは、コマンドラインオプションを処理するためのPerl4の パッケージのplethora(過多）です。
もし既存のモジュールセットを拡張するためにモジュールを書いて いるのなら、そのパッケージの著者と協調していただきたいのです。 あなたがオリジナルの著者と同じ命名大系やモジュール対話大系に従えば、 （利用する人が）助かります。
If you are writing a module to expand an already existing set of modules, please coordinate with the author of the package. It helps if you follow the same naming scheme and module interaction scheme as the original author.
2.2 拡張しやすく再利用しやすいように新しいモジュールを 設計してください。
ブレースされた参照を使って下さい。コンストラクターの 最初のパラメータとして与えられたクラス名をブレースするには blessの２引数形式を使って下さい。 例）
sub new {
my $class = shift;
return bless {}, $class;
}
あるいは、静的または仮想メソッドとして使用するのが好みであれば
これでさえ可。
sub new {
my $self = shift;
my $class = ref($self) || $self;
return bless {}, $class;
}
参照として配列を渡すと、さらに多くのパラメータを あとで加えることができます（またさらに早くなります）。 関数を適切なメソッドに変換して下さい。 大きなメソッドはより小さく柔軟なメソッドに分割して下さい。
die "Invalid" unless ref $ref eq 'FOO'; のような クラス名テストは避けて下さい。 通常、何の害もなく "eq 'FOO'" の部分は削除できます。 オブジェクトには自分で自分の世話をさせましょう！ 一般に、できるだけhardwiredなクラス名は避けて下さい。 @ISA=qw(... Class ...)としたり、$r->func()が使える ところでは、$r->Class::func()を使うのは避けて下さい。 （詳細はperlpod manページを参照して下さい）
autosplitを使って下さい。 そうすれば、ほとんど使われない 関数や新しく付け加えられた関数が、それらを使わないプログラムの負荷に なるようなことはなくなります。モジュールにはテスト関数を、 __END__ の後につけ加えて下さい。 AutoSplitを使うか下記のようにするか どちらでもいいです。
eval join('',) || die $@ unless caller();
あなたのモジュールは '空のサブクラス' テストを通りましたか？
もし"@SUBCLASS::ISA = qw(YOURCLASS);" とすれば、あなたの
アプリケーションは、YOURCLASSとまさしく同じ方法でSUBCLASSを使うことが
できるはずです。例えば、$obj = new YOURCLASS; を $obj = new SUBCLASS; に
変更しても、あなたのアプリケーションはまだ機能しますか？
ステート情報(state information)を、あなたのパッケージ内に保持するのは 避けて下さい。複数の他パッケージにとって、あなたのパッケージを利用する ことが困難になってしまいます。 ステート情報はオブジェクトの中に保持して下さい。
常に -w を使って下さい。"use strict;" (または"use strict qw(...);")を 試して下さい。あまり厳密さが必要でない個々のコードプロックには "no strict qw(...);"をつけ加えることができることを銘記しておいて下さい。 常に -w 。常に -w ！ perlstyle(1) マニュアルにある ガイドラインに従って下さい。
2.3 いくつかの簡単なスタイルガイドライン
perlとともに供給されるスタイルマニュアルには、多くの有用な点があります。
コーディングスタイルは個人の好みの問題です。、多くの人々が 、良いコードを書いたり保守したりするのに助けになることを学び、 ここ数年来そのスタイルを変えてきました。ここには、経験豊かな開発者たちが 広く使用していると思われる一連の提案があります。
ワードを分割するにはアンダースコアを使って下さい。一般に$VarNamesLikeThis より$var_names_like_thisの方が読みやすいでしょう。特に非英語圏の人々に とってはなおさらです。 一貫してVAR_NAMES_LIKE_THIS（このように変数名は 大文字）を使うというのも簡単なルールです。
パッケージ／モジュール名はこのルールの例外です。Perlはinteger やstrictの ような'pragma'モジュール用に、小文字のモジュール名を例外的に予約してい ます。他のモジュールは正式には小文字で始まり、（短くポータブルにする為） アンダースコアを使わず大文字小文字を混用しています。
変数のスコープや性質を示すのにレターケースを使うと有用なのにお気づきで しょう。例えば、
$ALL_CAPS_HERE 定数のみ(perl変数との衝突にご用心）
$Some_Caps_Here パッケージ全体でのグローバル／スタティック
$no_caps_here スコープ関数 my() や local()での変数
関数とメソッド名は全部小文字とするのが最もうまく機能するように思われます。
$obj->as_string()
変数や関数は、それが定義されているパッケージの外側で使われるべきではない
ということを示すために、前置きアンダースコアを使ってもよいでしょう。
メソッドコール用にはどちらも使えます。
$foo = new Foo $arg1, $arg2; # no parentheses
$foo = Foo->new($arg1, $arg2);
しかし、曖昧な形式は避けて下さい。
$foo = new Foo($arg1, $arg2); # Foo() looks like function call
コンストラクタの失敗の報告の仕方について、Larryはこう言いました：
私にはオブジェクトをコンストラクトできない場合、真のPerl例外(die)を throwすることで例外は十分とする傾向があります。これには、直ちに有利と なる点が２つかあります。第一に、各コンストラクタの戻り値をチェックする必要が ありません。単に "$fido = new Doggie;" と述べ、成功したと推定します。 大抵のケースでは、これでより明確なコードを導けます。
第２に、失敗してしまった場合、単なる戻り値の不確定さより、さらによい 診断を得ます。実際、throwする例外は、その中でさらに捕らえられた例外を 再throwしている場合には、「スタックされた」エラーメッセージ中に多くの 物を持っているものです
eval {}を使うなら、常に例外を捕獲できるでしょう。
一方、コンストラクタが相当な期間は失敗するであろうと予想される場合は 例外を使うべきではなく、インターフェースを文書化しておくべきです。 そうすれば、人々は戻り値をチェックすべきことを知るでしょう。 コンストラクタは真の参照あるいは偽の未定義を戻すだけなので、 defined()を使う必要はありません。 ですから、戻り値をチェックするためのよいPerlスタイルは単にこう 述べるだけです。
$conn = new Connection $addr
or die "Couldn't create Connection";
一般に、Booleanコンテキスト中では、できるだけ多くの意味を
表すものを作って下さい。これでまっすぐなコードを導けます。
Perlでは決してこんなふうには書かないで下さい。
if (do_your_thing() == OK)
論理的エラーとドメインエラーを訊ねられます。
単にこう書きましょう。
if (do_your_thing())
Perlは本来不明瞭さを避けやすくなるようデザインされているのです。
2.4 エキスポートすべきものを選択する。
メソッド名をエキスポートしないで下さい！ さしたる理由もないのにデフォルトで何か他のものをエキスポート したりしないで下さい！
エキスポートはモジュール利用者の名称スペースを汚染します。 どうしてもエキスポートしなければならないのなら、@EXPORTより むしろ@EXPORT_OKを使ってみて下さい。また、名称衝突の危険を減らすため、 短い名称やありきたりな名称は避けて下さい。
一般に、エキスポートされていないものはみんな、モジュール名::項目_名 （あるいは$blessed_ref->method）文法を使えば、モジュールの外から なおアクセス可能です。慣習により、'内部的な'ものでありパブリック使用の ためではないと非公式に示すために、名称の前にアンダースコアを使用する ことができます。
（実際には、my $subref = sub { ... }; &$subref; のようにして、 プライベート関数を手に入れることは可能です。しかし、メソッドとして 直接それをコールする方法はありません。メソッドは、シンボルテーブルに その名称を持っていなければならないからです。） 一般的なルールとして、モジュールがオブジェクト指向であろうとするなら、 何もエキスポートしてはなりせん。もし、それが単なる関数のコレクションなら、 決して@EXPORTを使わず、注意して@EXPORT_OKを使うことです。
2.5 モジュール用の名称を選択する。
この名称はできるだけ説明的であり、正確であり、完全であるべきです。 曖昧さのあらゆる危険を避けて下さい。常に全部で二語以上以上 使用するよう心がけて下さい。一般に名称は、どうやるのかということよりも、 モジュールが何をすることについて抜きん出ているかを反映すべきです。
全部Sortと呼ばれる57モジュールを持つことは、誰にとっても人生を 楽にする物ではないでしょう （Sort::Quick と呼ばれる23モジュールを持つのは、わずかばかりましですが）。 誰かがあなたのモジュールをたくさんの他のモジュールといっしょに インストールしようとしているのを想像してみて下さい。 何か疑問があるなら、comp.lang.perl.miscに提案して下さい。
モジュールを略式に分類したり層別したりするために、入れ子になった モジュール名を使って下さい。例えば、sortingモジュールであれば、 Sort::のカテゴリに入れます。 特に理由がないのなら、モジュールは入れ子になった名称を 持たなけらばなりません。モジュール名に１レベル以上の入れ子（ネスト） を使うのは避けて下さい。（当然、モジュール内のパッケージやクラスは、 いくつでも使うことができます。）
モジュール名は大文字で始まるべきです。 小文字名は実用pragmas（例；lib や strict）のように特別なモジュール用に 予約されています。
モジュール名はクラス階層に関連しません。 モジュール名Foo::Barは、あらゆる意味において、Foo::BarがFooからの継承で あるということを暗示するものではありません。ネストされた名前は単に人間の 向けに、いくつかの有用なカテゴリを提供するように利用されているのです。 一般に同じ事が全てのパッケージ名についてもあてはまります。
もしあなたがひと揃いの関連したモジュール／クラスを開発しているなら、 ネストされたクラスを共通接続詞とともに使うのは、名前空間のクラッシュを 避けるのにいい練習となります。例えば、Xyz::Control、Xyz::View、Xyz::Model、 その他。命名ガイドとしてこのリストの中のモジュールを使って下さい。
もしあるセットに新しいモジュールを加えるのなら、モジュールの命名法と それらのモジュールの中のメソッドとのインターフェースについては、 オリジナルの著者の標準に従ってください。
移植可能にするには、モジュール名の各コンポーネントを、11字内に 制限すべきです。DOS上で使用される見込みがあるなら、確実に最初の 8字以内で唯一のものにするよう心がけて下さい。
2.6 あなたはそれを正しくやってのけましたか？（Have you got it right?）
あなたは自分が正しい判断をしたかどうか、どうしたらわかりますか？ 後で問題を引き起こしたかもしれないインターフェースデザインを選び出した ことがありますか？最も適切な名前を選び出したことがありますか？ 何か質問をしたことがありますか？
確実に知るための、そしてたくさんの助言を拾い集めるための最良の方法は、 知っている人に訊ねることです。 Usenet のニュースグループであるcomp.lang.perl.misc および comp.lang.perl.moduleはは、モジュールを開発しているほとんど全ての人々に 購読されており、訊ねるには最良の場所です。 （訳者注：日本では fj.lang.perlがあります。）
あなたがなす必要のあるすべてのことはモジュールの要約、その目的や インターフェースを投稿することです。各主要メソッドを数行にまとめるだけで たぶん十分です。（もし全モジュールを投稿すれば、多忙な人−通常あなたが それを読んで欲しいと思っている人たち−には無視されるかもしれません。
モジュールがいつ準備できるか話すことができなくとも、投稿について心配する ことはありません。−ただメッセージのなかでそう述べればいいのです。 それはあなたを助ける人を招待するのに十分でしょう。その人達はあなたのために、 それを完成させることができるかもしれないのです。
2.7 README と他の付加的なファイル
通常、ソフトウェア開発は自分たちが書いたソフトウェアを完全に文書化する事は よく知られています。しかしながら、もし世界があなたのソフトウェアを緊急に 必要としていて、完全な文書を書く時間があまりない場合、少なくとも以下の内容を 含んだREADMEファイルを提供して下さい。
−モジュール／パッケージ／拡張等の記述 −著作権の告知（notice）− 下記参照 −必要条件 − その他必要とするかもしれない物 −構築方法 − Makefile.PL等へのあるかもしれない変更 −インストール方法 −このリリースでの新しい変更点、特に非互換性 −将来予定している変更／拡張もしREADMEファイルがあまりに大きすぎると思われるなら、インストール用、複写用、 実行（ToDo）用などのいくつか章に分割し、複数のファイルに分けてしまっても かまわないでしょう。
2.8 著作権の告知の追加
あなたの作品の使用を認可するかどうかの選択は、個人が決定するものです。 一般的な機構は、あなたの著作権の存在を明らかに示し、そして他の人が作品を 複写／使用／変更してもよいかどうかの宣言を行います。
例えば、Perlは２つのタイプのライセンスで供給されています。GNU GPLと芸術的 ライセンス(The Artistic License)です。(README、Copying、Artisticの各ファイル参照）。 LarryがGNU GPLを単に使用しないのにはそれなりの理由があります。
私の個人的な推奨は、Larryに対する敬意を除いて(out of respect for Larry)、 Perlおよびperl共同体全般は、次のように簡単に述べてしまうということです。
Copyright (c) 1995 あなたの名前。 All rights reserved. このプログラムはフリーソフトウェアです。あなたはPerl自身と同じ条件の元 でそれを再配布および／あるいは修正することができます。
この宣言は少なくともRREADMEファイルには現れるようにすべきです。また、Copying ファイルやあなたのソースファイルの中に含むようにしても構わないでしょう。 著作権表示に加え、他の言葉を含ませておくことを銘記して下さい。
2.9 バージョン／発行／公開番号をモジュールに付与する。
ExporterやMakeMakerモジュールと完全な互換性を持たせるには、$VERSION と 呼ばれる非myパッケージ変数の中にモジュールのバージョン番号を保管すべきであり、 少なくとも小数点以下２桁を使用すべきです（例：100分の１単位、 $VERSION = "0.01"）。"1.3.2"のようなスタイルのバージョンは使わないで下さい。 詳細は、Perl5.001m以降のExporter.pmを参照して下さい。
番号を検索する関数やメソッドを加えると便利かもしれません。 発表にはその番号を使い、モジュールを公開する際には、アーカイブファイル名を 使って下さい(モジュール名称-1.02.tar.Z)。 詳細はperldoc ExtUtils::MakeMaker.pm を参照して下さい。
2.10 モジュールの公開及び配布方法
あなたのモジュールの有用性の発表（あるいはもしモジュールが小さいようなら モジュール自体）をUsenetのニュースグループのcomp.lang.perl.announceに投稿するのは よい考えです。これは少なくとも非常に広い一斉（once-off）配布を確実にするでしょう。
もし可能なら、主要なftpアーカイブにそのモジュールを置き、発表にその場所の詳細を 含めておくとよいでしょう。
ftpアーカイブについてのいくつかの注意事項： バージョン番号を含む長い自己説明的なファイル名を使って下さい 。大半のincomingディレクトリーは読み取り可能／検索可能ではないでしょう。 換言すれば、アップロードした後は自分のファイルを見ることはできなくなります。 アップロード後はできるだけ早く電子メール(email)確認メッセージを送ることを銘記してください。 さもないとあなたのファイルは自動的に削除されてしまうかもしれません。 場所を発表する前に、ファイルを処理する、および／あるいは、ファイルが処理 されたかどうか確認する時間を見込んでおいて下さい。
Perlモジュール用FTPアーカイブ:
下記の指示およびリンクに従ってください。
http://www.perl.com/CPAN/modules/04pause.html
あるいは、下記サイトのいずれかにアップロードしてください。
ftp://franz.ww.tu-berlin.de/incoming (推奨)
ftp://ftp.cis.ufl.edu/incoming
それから、upload@franz.ww.tu-berlin.de 宛連絡してください。
WWWインターフェースを利用することで、自分のftpサイトあるいはWWWサイトから CPAN上のあなた自身のディレクトリに、あなたのモジュールをミラーするよう、 アップロードサーバーに依頼することが可能になります。くれぐれも、 モジュールリスト掲載用の更新登録を私達に送るのを忘れないで下さい！
2.11 公開したモジュールを変更する際の注意
常に、以前の公開バージョンとの互換性をなんとか残すよう努力して下さい（上記2.2参照）。 どうしても駄目な場合（otherwise)、もし人々が以前の動作に依存しているのなら、 それに戻すような機構を加えるよう試みて下さい。非互換となった変更点の文書を発行して下さい。
もし、だめにならないのなら、直さないことです！ Perl4ライブラリーのス クリプトは問題なく動き続けるはずです。 （二重引用符で囲った文字列の中で非配列の@等をエスケープするような） いくつかのマイナーな修正を行うことは必要かもしれませんが、 .plファイルをモジュールに変換する必要はないのです。
3.2 言外の意味を熟慮して下さい。
スクリプトがモジュールに変換されるなら、そのスクリプトを利用するすべての perlアプリケーションは（わずかながら）修正する必要が出てくるでしょう。 あなたが同時に他の変更を行う計画がないのでしたら、その変換は（行うに） 値することなのでしょうか？
3.3 好機を最大限活かして下さい。(Make the most of the opportunity.)
スクリプトをモジュールに変換する予定なら、インターフェースを再設計する好機です。 上記「モジュール創作のためのガイドライン」はあなたが熟考すべき多くの問題を包含しています。
3.4 pl2pmユーティリティがあなたを始動させるでしょう。
このユーティリティは（パラメータとして与えられた）*.plファイルを読み込み、 対応する*.pmファイルに書き出します。pl2pmユーティリティは次のようなことを行います。：
−標準的モジュールプロローグラインを追加 −パッケージspecifiersを ' から :: に変換 −die(...) を croak(...) に変換 −いくつかの他のマイナーな変更pl2pmが機械的プロセスであるということは、防弾であるということではありません。変換されたコードは、特にあらゆるパッケージステートメントを、注意深く照査される必要があるでしょう。新しい .pmファイルが動くまでは、オリジナルの .plファイルを削除しないで下さい。
4.1 完全なアプリケーションはめったにPerlモジュールライブラリーには属しません。
4.2 多くのアプリケーションは再利用できるperlコードを含んでいます。
助け合いは世界を救う！ 再利用し易くする一定の様式で、あなたのコードを分かち合いましょう。
4.3 再利用可能なコードをひとつあるいは複数の分割されたファイルに引き出して下さい(break-out)。
4.4 インターフェースについて再考、再設計する機会をうまく使って下さい。
4.5 いくつかの事例では、 'アプリケーション' は、再利用可能なモジュールの最上位に構築された小さなコードの断片にまとめることができます。この場合、アプリケーションは以下のように呼び出されるでしょう。：
perl -Mモジュール::名前 -e '関数(@ARGV)'
=======================================================================
ご意見、ご要望は、
電子メールまたは
投稿にお願い致します。ホームページへ戻る。