argra****@users*****
argra****@users*****
2008年 5月 29日 (木) 00:41:30 JST
Index: docs/perl/5.10.0/perltooc.pod
diff -u /dev/null docs/perl/5.10.0/perltooc.pod:1.1
--- /dev/null Thu May 29 00:41:30 2008
+++ docs/perl/5.10.0/perltooc.pod Thu May 29 00:41:30 2008
@@ -0,0 +1,2759 @@
+
+=encoding euc-jp
+
+=head1 NAME
+
+=begin original
+
+perltooc - Tom's OO Tutorial for Class Data in Perl
+
+=end original
+
+perltooc - トムによる Perl のクラスデータのためのオブジェクト指向チュートリアル
+
+=head1 DESCRIPTION
+
+=begin original
+
+When designing an object class, you are sometimes faced with the situation
+of wanting common state shared by all objects of that class.
+Such I<class attributes> act somewhat like global variables for the entire
+class, but unlike program-wide globals, class attributes have meaning only to
+the class itself.
+
+=end original
+
+オブジェクトクラスを宣言するとき、共通の状態をクラスの全てのオブジェクトが
+共有したい状況に直面することがあります。
+そのような I<クラス属性> は、いくぶん、クラス全体のグローバル変数のように
+はたらきます。
+ですが、プログラム全体のグローバル変数とは違い、クラス属性は、クラス
+それ自身にとってのみグローバルです。
+
+=begin original
+
+Here are a few examples where class attributes might come in handy:
+
+=end original
+
+クラス属性が役に立つ例がいくつかあります。
+
+=over 4
+
+=item *
+
+=begin original
+
+to keep a count of the objects you've created, or how many are
+still extant.
+
+=end original
+
+生成したオブジェクトの数を保っておくために。
+また、まだいくつあるのかを数えておくために。
+
+=item *
+
+=begin original
+
+to extract the name or file descriptor for a logfile used by a debugging
+method.
+
+=end original
+
+デバッグメソッドで使われるログファイルの名前か、ファイル識別子を
+引き出すために。
+
+=item *
+
+=begin original
+
+to access collective data, like the total amount of cash dispensed by
+all ATMs in a network in a given day.
+
+=end original
+
+全体的なデータにアクセスするために。
+たとえば、与えられた日の、ネットワークの全 ATM で支払われた現金の
+総金額のようなものにアクセスするために。
+
+=item *
+
+=begin original
+
+to access the last object created by a class, or the most accessed object,
+or to retrieve a list of all objects.
+
+=end original
+
+クラスによって、最後に作られたオブジェクトにアクセスするために、
+また、もっともアクセスされたオブジェクトにアクセスするために、
+また、すべてのオブジェクトのリストを検索するために。
+
+=back
+
+=begin original
+
+Unlike a true global, class attributes should not be accessed directly.
+Instead, their state should be inspected, and perhaps altered, only
+through the mediated access of I<class methods>. These class attributes
+accessor methods are similar in spirit and function to accessors used
+to manipulate the state of instance attributes on an object. They provide a
+clear firewall between interface and implementation.
+
+=end original
+
+本当のグローバル変数とは違って、クラス属性は直接にアクセスされるべきでは
+ありません。
+直接にアクセスされるべきではありませんが、クラス属性の状態は
+調べられるべきですし、たぶん、変更もされるべきです。
+ただし、I<クラスメソッド> を仲介して、アクセスすることを通してのみです。
+クラス属性のアクセサメソッドは、気持ちと、機能の上では、
+オブジェクトのインスタンス属性の状態を操作するのに使われるアクセサに
+似ています。
+これらは、インターフェースと実装の間に透明なファイアウォールを提供します。
+
+=begin original
+
+You should allow access to class attributes through either the class
+name or any object of that class. If we assume that $an_object is of
+type Some_Class, and the &Some_Class::population_count method accesses
+class attributes, then these two invocations should both be possible,
+and almost certainly equivalent.
+
+=end original
+
+クラス属性へのアクセスは、クラスの名前か、クラスのオブジェクトのどちらを
+通してもできるようにすべきです。
+$an_object が、Some_Class の型のもので、
+&Some_Class::population_count メソッドがクラス属性にアクセスするとします。
+そうすると、2 つの呼び出しが両方とも可能であるべきです。
+そして、もちろん、ほとんど同じであるべきです。
+
+ Some_Class->population_count()
+ $an_object->population_count()
+
+=begin original
+
+The question is, where do you store the state which that method accesses?
+Unlike more restrictive languages like C++, where these are called
+static data members, Perl provides no syntactic mechanism to declare
+class attributes, any more than it provides a syntactic mechanism to
+declare instance attributes. Perl provides the developer with a broad
+set of powerful but flexible features that can be uniquely crafted to
+the particular demands of the situation.
+
+=end original
+
+疑問があります。
+このメソッドがアクセスする、その状態をどこに置いておくのでしょうか?
+C++ のような、より厳格な言語とは違って、Perlには静的なデータメンバと
+呼ばれる場所はありません。
+Perl は、クラス属性を宣言するのに、総合のメカニズムはまったく提供しません。
+インスタンス属性を宣言する総合のメカニズムしかありません。
+Perl は開発者に、特殊な状況の要求にも、うまく作ることのできる、
+強力ですが、柔軟な、大まかなセットを提供します。
+
+=begin original
+
+A class in Perl is typically implemented in a module. A module consists
+of two complementary feature sets: a package for interfacing with the
+outside world, and a lexical file scope for privacy. Either of these
+two mechanisms can be used to implement class attributes. That means you
+get to decide whether to put your class attributes in package variables
+or to put them in lexical variables.
+
+=end original
+
+Perlのクラスは、典型的にモジュールに実装されます。
+モジュールは、2 つの相補的な特徴の組合わせで、できています：外の世界との
+インターフェースのためのパッケージと、プライバシーのためのレキシカルな
+ファイルスコープのセットです。
+これらの 2 つのメカニズムの両方を、クラス属性の実装に使うことができます。
+このことは、すなわち、クラス属性をパッケージ変数に置くか、
+レキシカル変数に置くかを決めることができるということです。
+
+=begin original
+
+And those aren't the only decisions to make. If you choose to use package
+variables, you can make your class attribute accessor methods either ignorant
+of inheritance or sensitive to it. If you choose lexical variables,
+you can elect to permit access to them from anywhere in the entire file
+scope, or you can limit direct data access exclusively to the methods
+implementing those attributes.
+
+=end original
+
+また、これらは、作るのにあたっての唯一の判断ではありません。
+パッケージ変数を選んだとしても、クラス属性アクセサメソッドに、継承を
+無視させるか、継承に反応させることもできます。
+レキシカル変数を選んだとしても、まったく、ファイルスコープの中の
+どこからでも、クラス属性にアクセスすることを許すこともできますし、また、
+直接データにアクセスするのを、
+排他的に、それらの属性を実装するメソッドだけに制限することも出来ます。
+
+=head1 Class Data in a Can
+
+(缶の中のクラスデータ)
+
+=begin original
+
+One of the easiest ways to solve a hard problem is to let someone else
+do it for you! In this case, Class::Data::Inheritable (available on a
+CPAN near you) offers a canned solution to the class data problem
+using closures. So before you wade into this document, consider
+having a look at that module.
+
+=end original
+
+難しい問題を解決するための、もっとも簡単な方法の一つは、誰か他の人に
+問題を解決させることです!
+この場合、Class::Data::Inheritable (お近くの CPAN で利用できます)が、
+クロージャを使うクラスデータの問題の決まりきった解決法を提供します。
+ですので、このドキュメントを苦労して読み進める前に、
+Class::Data::Inheritable モジュールを見ることを検討してください。
+
+
+=head1 Class Data as Package Variables
+
+(パッケージ変数としてクラスデータを)
+
+=begin original
+
+Because a class in Perl is really just a package, using package variables
+to hold class attributes is the most natural choice. This makes it simple
+for each class to have its own class attributes. Let's say you have a class
+called Some_Class that needs a couple of different attributes that you'd
+like to be global to the entire class. The simplest thing to do is to
+use package variables like $Some_Class::CData1 and $Some_Class::CData2
+to hold these attributes. But we certainly don't want to encourage
+outsiders to touch those data directly, so we provide methods
+to mediate access.
+
+=end original
+
+Perlのクラスは、本当に、ただのパッケージなので、クラス属性を持つのに、
+パッケージ変数を使うのはもっとも自然な選択です。
+つまり、パッケージに、単純にそれ自身のクラス属性をもたせるのです。
+例えば、クラス全体にグローバルであるような、異なった属性がいくつか必要な
+Some_Class というクラスがあるとします。
+もっとも簡単なのは、$Some_Class::CData1 や$Some_Class::CData2 のような
+パッケージ変数を使い、これらの属性を持たせることです。
+ですが、もちろん部外者がこれらのデータディレクトリに触ることを
+勧めたくはありません。
+ですので、アクセスを仲介するメソッドを提供します。
+
+=begin original
+
+In the accessor methods below, we'll for now just ignore the first
+argument--that part to the left of the arrow on method invocation, which
+is either a class name or an object reference.
+
+=end original
+
+下の、アクセサメソッドで、今のところ、第一引数 -- メソッド呼び出しの矢印の
+左の部分で、クラスの名前か、オブジェクトリファレンス -- を、無視しています。
+
+=begin original
+
+ package Some_Class;
+ sub CData1 {
+ shift; # XXX: ignore calling class/object
+ $Some_Class::CData1 = shift if @_;
+ return $Some_Class::CData1;
+ }
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ $Some_Class::CData2 = shift if @_;
+ return $Some_Class::CData2;
+ }
+
+=end original
+
+ package Some_Class;
+ sub CData1 {
+ shift; # XXX: クラス/オブジェクト呼び出しを無視します
+ $Some_Class::CData1 = shift if @_;
+ return $Some_Class::CData1;
+ }
+ sub CData2 {
+ shift; # XXX: クラス/オブジェクト呼び出しを無視します
+ $Some_Class::CData2 = shift if @_;
+ return $Some_Class::CData2;
+ }
+
+=begin original
+
+This technique is highly legible and should be completely straightforward
+to even the novice Perl programmer. By fully qualifying the package
+variables, they stand out clearly when reading the code. Unfortunately,
+if you misspell one of these, you've introduced an error that's hard
+to catch. It's also somewhat disconcerting to see the class name itself
+hard-coded in so many places.
+
+=end original
+
+このテクニックは、非常に読みやすく、普通のPerlプログラマにとってさえ、
+完全に直接です。
+パッケージ変数を完全に修飾することで、コードを読むときに、はっきりと、
+目立ちます。
+不運なことに、もし、これらの一つでも、スペルを間違えたら、捕まえがたい
+エラーを持ち込むことになります。
+また、クラスの名前自身を多くの場所にハードコードしているのを見るのは、
+いくぶんイライラもさせます。
+
+=begin original
+
+Both these problems can be easily fixed. Just add the C<use strict>
+pragma, then pre-declare your package variables. (The C<our> operator
+will be new in 5.6, and will work for package globals just like C<my>
+works for scoped lexicals.)
+
+=end original
+
+この 2 つの問題は、両方とも簡単に修正できます。
+C<use strict> プラグマを加え、それから、パッケージ変数を先に
+宣言するだけです。
+(C<our> 演算子は、5.6 の、新しいものです。
+C<my> がスコープされたレキシカル変数に働くのと同じように、パッケージの
+グローバル変数に働きます。)
+
+=begin original
+
+ package Some_Class;
+ use strict;
+ our($CData1, $CData2); # our() is new to perl5.6
+ sub CData1 {
+ shift; # XXX: ignore calling class/object
+ $CData1 = shift if @_;
+ return $CData1;
+ }
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ $CData2 = shift if @_;
+ return $CData2;
+ }
+
+=end original
+
+ package Some_Class;
+ use strict;
+ our($CData1, $CData2); # our() is new to perl5.6
+ sub CData1 {
+ shift; # XXX: クラス/オブジェクト呼び出しを無視します
+ $CData1 = shift if @_;
+ return $CData1;
+ }
+ sub CData2 {
+ shift; # XXX: クラス/オブジェクト呼び出しを無視します
+ $CData2 = shift if @_;
+ return $CData2;
+ }
+
+=begin original
+
+As with any other global variable, some programmers prefer to start their
+package variables with capital letters. This helps clarity somewhat, but
+by no longer fully qualifying the package variables, their significance
+can be lost when reading the code. You can fix this easily enough by
+choosing better names than were used here.
+
+=end original
+
+他のどのグローバル変数とも同じように、
+これらパッケージ変数を大文字で始めるのを好むプログラマがいます。
+このことは、いくぶん明瞭さを助けますが、パッケージ変数がまったく
+修飾されていないので、コードを読むときにその重要性が失われるかもしれません。
+これを修正するのは簡単で、ここで使われているよりも、もっと良い名前を選べば
+事足ります。
+
+=head2 Putting All Your Eggs in One Basket
+
+(卵をみんな、一つのバスケットに置く)
+
+=begin original
+
+Just as the mindless enumeration of accessor methods for instance attributes
+grows tedious after the first few (see L<perltoot>), so too does the
+repetition begin to grate when listing out accessor methods for class
+data. Repetition runs counter to the primary virtue of a programmer:
+Laziness, here manifesting as that innate urge every programmer feels
+to factor out duplicate code whenever possible.
+
+=end original
+
+ちょうど、インスタンス属性のアクセサメソッドを思慮なく列挙するのが、
+最初の数回の後には、飽き飽きするものになっていくように(L<perltoot> を参照)、
+クラスデータのアクセサメソッドをリストするときも、
+同じことのくり返しに、非常にイライラしてくるでしょう。
+くり返しは、プログラマの主要な美徳、不精に反します。
+ここでは、あらゆるプログラマが感じる生まれつきの衝動が、
+出来るかぎりコードの二重化を睨むものとして現れます。
+
+=begin original
+
+Here's what to do. First, make just one hash to hold all class attributes.
+
+=end original
+
+次のようにすべきです。
+最初に、全てのクラス属性を持つハッシュをただ一つ、作ります。
+
+ package Some_Class;
+ use strict;
+ our %ClassData = ( # our() is new to perl5.6
+ CData1 => "",
+ CData2 => "",
+ );
+
+=begin original
+
+Using closures (see L<perlref>) and direct access to the package symbol
+table (see L<perlmod>), now clone an accessor method for each key in
+the %ClassData hash. Each of these methods is used to fetch or store
+values to the specific, named class attribute.
+
+=end original
+
+クロージャ(L<perlref> 参照)を使って、パッケージのシンボルテーブル
+(L<perlmod> 参照)に直接にアクセスします。
+さて、%ClassData ハッシュの中のそれぞれのキーごとに、アクセサメソッドを
+クローニングします。
+これらのメソッドは、値を持ってくるか、特定の指定されたクラス属性に値を
+格納するために使われます。
+
+=begin original
+
+ for my $datum (keys %ClassData) {
+ no strict "refs"; # to register new methods in package
+ *$datum = sub {
+ shift; # XXX: ignore calling class/object
+ $ClassData{$datum} = shift if @_;
+ return $ClassData{$datum};
+ }
+ }
+
+=end original
+
+ for my $datum (keys %ClassData) {
+ no strict "refs"; # パッケージに新しいメソッドを登録するために
+ *$datum = sub {
+ shift; # XXX: クラス/オブジェクトの呼出を無視する
+ $ClassData{$datum} = shift if @_;
+ return $ClassData{$datum};
+ }
+ }
+
+=begin original
+
+It's true that you could work out a solution employing an &AUTOLOAD
+method, but this approach is unlikely to prove satisfactory. Your
+function would have to distinguish between class attributes and object
+attributes; it could interfere with inheritance; and it would have to
+careful about DESTROY. Such complexity is uncalled for in most cases,
+and certainly in this one.
+
+=end original
+
+&AUTOLOADメソッドを用いる解決法も、うまくはいきますが、このアプローチを
+満足の行くものであると立証するのは、見込がありません。
+関数はクラス属性とオブジェクト属性の間を区別しなければなりません。
+継承に干渉します。
+また、DESTORY に注意する必要があります。
+このような複雑性は、ほとんどの場合でお呼びではありません。
+もちろん、この場合も。
+
+=begin original
+
+You may wonder why we're rescinding strict refs for the loop. We're
+manipulating the package's symbol table to introduce new function names
+using symbolic references (indirect naming), which the strict pragma
+would otherwise forbid. Normally, symbolic references are a dodgy
+notion at best. This isn't just because they can be used accidentally
+when you aren't meaning to. It's also because for most uses
+to which beginning Perl programmers attempt to put symbolic references,
+we have much better approaches, like nested hashes or hashes of arrays.
+But there's nothing wrong with using symbolic references to manipulate
+something that is meaningful only from the perspective of the package
+symbol table, like method names or package variables. In other
+words, when you want to refer to the symbol table, use symbol references.
+
+=end original
+
+なぜ、strict refs をループで無効にしているのだろうと思うかも知れません。
+パッケージのシンボルテーブルを操作して、新しい関数名をシンボリック
+リファレンスを使って(間接的な命名で)導入しています。
+シンボリックリファレンスは、strict プラグマが禁じているものです。
+ふつうは、シンボリックリファレンスは、せいぜい危なっかしい考えです。
+ただ、意図しないときに、あやまって使われる可能性があるので、危なっかしいと
+いうだけです。
+初心者の Perl プログラマがシンボリックリファレンスを置こうとする、
+使いかたのほとんどには、ネストされたハッシュや配列のハッシュのような、
+より良いアプローチがあるからです。
+ですが、メソッド名やパッケージ変数のようなパッケージのシンボルテーブルの
+観点からのみ、意味があることを操作するのに、シンボリックリファレンスを
+使うのは、何も間違っていません。
+言い替えれば、シンボルテーブルを参照したい場合は、シンボリックリファレンスを
+使ってください。
+
+=begin original
+
+Clustering all the class attributes in one place has several advantages.
+They're easy to spot, initialize, and change. The aggregation also
+makes them convenient to access externally, such as from a debugger
+or a persistence package. The only possible problem is that we don't
+automatically know the name of each class's class object, should it have
+one. This issue is addressed below in L<"The Eponymous Meta-Object">.
+
+=end original
+
+一つの場所に、全てのクラス属性を集積するのは、さまざまな利点があります。
+クラス属性は、目に付きやすく、初期化しやすく、変更しやすい。
+集約することで、クラス属性を外部から、例えば、デバッガや永続的な
+パッケージから、アクセスするのが便利になります。
+唯一ありそうな問題は、それぞれのクラスが持っているはずの
+クラスオブジェクトの名前を自動的には知らないことです。
+この問題は、下の方の L<"The Eponymous Meta-Object"> に、扱われています。
+
+=head2 Inheritance Concerns
+
+(継承の懸念)
+
+=begin original
+
+Suppose you have an instance of a derived class, and you access class
+data using an inherited method call. Should that end up referring
+to the base class's attributes, or to those in the derived class?
+How would it work in the earlier examples? The derived class inherits
+all the base class's methods, including those that access class attributes.
+But what package are the class attributes stored in?
+
+=end original
+
+派生クラスのインスタンスがあったとして、継承されたメソッド呼び出しを使い、
+クラスデータにアクセスします。
+このとき、結局、基底クラスの属性を参照することになるべきなのか、
+派生クラスの属性を参照することになるべきでしょうか？
+さっきの例ではどのように動くでしょうか？
+派生クラスは基底クラスの全てのメソッドを継承します。
+クラス属性にアクセスするメソッドも含みます。
+ですが、どのパッケージにクラス属性が格納されるのでしょうか？
+
+=begin original
+
+The answer is that, as written, class attributes are stored in the package into
+which those methods were compiled. When you invoke the &CData1 method
+on the name of the derived class or on one of that class's objects, the
+version shown above is still run, so you'll access $Some_Class::CData1--or
+in the method cloning version, C<$Some_Class::ClassData{CData1}>.
+
+=end original
+
+答えは、書かれたように、クラス属性はそれらのメソッドがコンパイルされた
+パッケージに、格納されます。
+&CData1 メソッドを、派生クラスの名前か、派生クラスのオブジェクトで呼び出すと、
+上で示されたバージョンのものが動きます。
+つまり、$Some_Class::Cdata1 -- または、クローニングしているバージョンの
+メソッドで、C<$Some_Class::ClassData{CData1}>に、アクセスできます。
+
+=begin original
+
+Think of these class methods as executing in the context of their base
+class, not in that of their derived class. Sometimes this is exactly
+what you want. If Feline subclasses Carnivore, then the population of
+Carnivores in the world should go up when a new Feline is born.
+But what if you wanted to figure out how many Felines you have apart
+from Carnivores? The current approach doesn't support that.
+
+=end original
+
+派生クラスのコンテキストではなく、
+基底クラスのコンテキストで実行するようなクラスメソッドを考えましょう。
+お望みのものにびったりなことがあります。
+猫は肉食動物の下位に分類されれば、新たに猫が生まれると、世界の肉食動物の
+固体数が増えます。
+ですが、肉食動物とは切り離して、何匹の猫がいるかを数えたいなら
+どうしましょう？
+現在のアプローチではそれには対応できません。
+
+=begin original
+
+You'll have to decide on a case-by-case basis whether it makes any sense
+for class attributes to be package-relative. If you want it to be so,
+then stop ignoring the first argument to the function. Either it will
+be a package name if the method was invoked directly on a class name,
+or else it will be an object reference if the method was invoked on an
+object reference. In the latter case, the ref() function provides the
+class of that object.
+
+=end original
+
+クラス属性が package-relative であることに筋が通っているかどうかを、
+ケースバイケースの根拠で決める必要があるでしょう。
+package-relative でありたいなら、関数の第一引数を無視するのをやめます。
+第一引数は、メソッドがクラス名で直接に呼ばれたなら、パッケージ名、
+オブジェクトリファレンスで呼ばれたなら、オブジェクトリファレンスの、
+どちらかです。
+後者では、ref() 関数がオブジェクトのクラス名を与えます。
+
+ package Some_Class;
+ sub CData1 {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ my $varname = $class . "::CData1";
+ no strict "refs"; # to access package data symbolically
+ $$varname = shift if @_;
+ return $$varname;
+ }
+
+=begin original
+
+And then do likewise for all other class attributes (such as CData2,
+etc.) that you wish to access as package variables in the invoking package
+instead of the compiling package as we had previously.
+
+=end original
+
+以前にしたようなコンパイルしているパッケージではなく、呼び出している
+パッケージのパッケージ変数としてアクセスしたいと思っている、
+他の全てのクラス属性(CData2 などのように)と同じようにしたいでしょう。
+
+=begin original
+
+Once again we temporarily disable the strict references ban, because
+otherwise we couldn't use the fully-qualified symbolic name for
+the package global. This is perfectly reasonable: since all package
+variables by definition live in a package, there's nothing wrong with
+accessing them via that package's symbol table. That's what it's there
+for (well, somewhat).
+
+=end original
+
+ここで、再び、一時的に strict references を禁止するのをやめましょう。
+そうしないと、パッケージのグローバル変数のために、完全に適格なシンボル名を
+使うことが出来ないからです。
+このことは、完全に合理的です：全てのパッケージ変数は、定義により、
+パッケージに生きています。
+パッケージのシンボル名経由で、パッケージ変数に
+アクセスするのは何も間違っていません。
+そのためにそれがあるのです(たぶん)。
+
+=begin original
+
+What about just using a single hash for everything and then cloning
+methods? What would that look like? The only difference would be the
+closure used to produce new method entries for the class's symbol table.
+
+=end original
+
+全てのもののために、ただ一つのハッシュを使い、メソッドを複製しては
+どうでしょうか？
+どのように見えるでしょう？
+唯一の違いは、クラスのシンボルテーブルに新しいメソッドを生み出すのに、
+クロージャが使われていることです。
+
+ no strict "refs";
+ *$datum = sub {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ my $varname = $class . "::ClassData";
+ $varname->{$datum} = shift if @_;
+ return $varname->{$datum};
+ }
+
+=head2 The Eponymous Meta-Object
+
+(クラスの名前のメタオブジェクト)
+
+=begin original
+
+It could be argued that the %ClassData hash in the previous example is
+neither the most imaginative nor the most intuitive of names. Is there
+something else that might make more sense, be more useful, or both?
+
+=end original
+
+前の例の、%ClassDataハッシュは、変数名が創意に富んでも、直観的でもないと、
+主張されるかもしれません。
+もっと意味があるか、有益なものか、その両方を備えたものはないでしょうか？
+
+=begin original
+
+As it happens, yes, there is. For the "class meta-object", we'll use
+a package variable of the same name as the package itself. Within the
+scope of a package Some_Class declaration, we'll use the eponymously
+named hash %Some_Class as that class's meta-object. (Using an eponymously
+named hash is somewhat reminiscent of classes that name their constructors
+eponymously in the Python or C++ fashion. That is, class Some_Class would
+use &Some_Class::Some_Class as a constructor, probably even exporting that
+name as well. The StrNum class in Recipe 13.14 in I<The Perl Cookbook>
+does this, if you're looking for an example.)
+
+=end original
+
+はい、ちょうどよくあります。
+"クラスのメタオブジェクト"に、パッケージと同じ名前のパッケージ変数を
+使いましょう。
+Some_Class のパッケージ宣言のスコープ内で、クラスのメタオブジェクトとして、
+%Some_Class という、クラスの名前のハッシュを使いましょう。
+(クラスの名前のハッシュは、コンストラクタをクラスの名前にする、
+Python や、C++ 流儀のクラスをちょっと思い出させます。
+つまり、Some_Class クラスが &Some_Class::Some_Class をコンストラクタと
+するということです。
+おそらく、その名前を同様にエクスポートさえしているでしょう。
+例をお探しなら、I<The Perl Cookbook> の StrNum クラスは、そのように
+しています)。
+
+=begin original
+
+This predictable approach has many benefits, including having a well-known
+identifier to aid in debugging, transparent persistence,
+or checkpointing. It's also the obvious name for monadic classes and
+translucent attributes, discussed later.
+
+=end original
+
+このありきたりなアプローチには、多くの利益があります。
+よくわかる一意の名前を含むことで、デバッグや透過的な永続生やチェックポイントの
+助けになります。
+後で述べる、一価のクラスと半透明な属性にとっても、明らかな名前です。
+
+=begin original
+
+Here's an example of such a class. Notice how the name of the
+hash storing the meta-object is the same as the name of the package
+used to implement the class.
+
+=end original
+
+下のものは、そのようなクラスの例です。
+メタオブジェクトを格納しているハッシュの名前が、どのようにして、
+クラスを実装するのに使われているパッケージの名前と同じに
+しているかに気を付けてください。
+
+ package Some_Class;
+ use strict;
+
+=begin original
+
+ # create class meta-object using that most perfect of names
+ our %Some_Class = ( # our() is new to perl5.6
+ CData1 => "",
+ CData2 => "",
+ );
+
+=end original
+
+ # 完全な名前を使ってクラスのメタオブジェクトを作る
+ our %Some_Class = ( # our() is new to perl5.6
+ CData1 => "",
+ CData2 => "",
+ );
+
+=begin original
+
+ # this accessor is calling-package-relative
+ sub CData1 {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ no strict "refs"; # to access eponymous meta-object
+ $class->{CData1} = shift if @_;
+ return $class->{CData1};
+ }
+
+=end original
+
+ # このアクセサはcalling-package-relative
+ sub CData1 {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ no strict "refs"; # to access eponymous meta-object
+ $class->{CData1} = shift if @_;
+ return $class->{CData1};
+ }
+
+=begin original
+
+ # but this accessor is not
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ no strict "refs"; # to access eponymous meta-object
+ __PACKAGE__ -> {CData2} = shift if @_;
+ return __PACKAGE__ -> {CData2};
+ }
+
+=end original
+
+ # こちらのアクセサは違います
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ no strict "refs"; # to access eponymous meta-object
+ __PACKAGE__ -> {CData2} = shift if @_;
+ return __PACKAGE__ -> {CData2};
+ }
+
+=begin original
+
+In the second accessor method, the __PACKAGE__ notation was used for
+two reasons. First, to avoid hardcoding the literal package name
+in the code in case we later want to change that name. Second, to
+clarify to the reader that what matters here is the package currently
+being compiled into, not the package of the invoking object or class.
+If the long sequence of non-alphabetic characters bothers you, you can
+always put the __PACKAGE__ in a variable first.
+
+=end original
+
+2 番目のアクセサで、__PACKAGE__ 記法が、2つの理由から使われています。
+1 つ目の理由は、後で、名前を変えたくなった際に、コードにパッケージの名前を
+リテラルでハードコーディングするのは避けたいからです。
+2 つ目の理由は、コードを読む人に、ここで何が問題なのかをはっきり
+させるためです。
+ここでの問題は、現在コンパイルされているパッケージであり、
+オブジェクトかクラスを呼び出したパッケージではないということです。
+アルファベットでない文字列が長く続くのが面倒なら、
+常に、変数の最初に、__PACKAGE__ を置いてください。
+
+=begin original
+
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ no strict "refs"; # to access eponymous meta-object
+ my $class = __PACKAGE__;
+ $class->{CData2} = shift if @_;
+ return $class->{CData2};
+ }
+
+=end original
+
+ sub CData2 {
+ shift; # XXX: クラス/オブジェクトの呼び出しを無視し、
+ no strict "refs"; # クラスの名前のメタオブジェクトにアクセスします。
+ my $class = __PACKAGE__;
+ $class->{CData2} = shift if @_;
+ return $class->{CData2};
+ }
+
+=begin original
+
+Even though we're using symbolic references for good not evil, some
+folks tend to become unnerved when they see so many places with strict
+ref checking disabled. Given a symbolic reference, you can always
+produce a real reference (the reverse is not true, though). So we'll
+create a subroutine that does this conversion for us. If invoked as a
+function of no arguments, it returns a reference to the compiling class's
+eponymous hash. Invoked as a class method, it returns a reference to
+the eponymous hash of its caller. And when invoked as an object method,
+this function returns a reference to the eponymous hash for whatever
+class the object belongs to.
+
+=end original
+
+ずっとシンボリックリファレンスを使っていますが、悪くはありません。
+ずいぶん多くの場所で、strict ref のチェックを無効にしているのに、
+うろたえがちな人がいるでしょうけど。
+シンボリックリファレンスであれば、常に、本当のリファレンスを作れます
+(その逆は真ではありませんが)。
+このシンボリックリファレンスから本当のリファレンスへの変換をする
+サブルーチンを作りましょう。
+引数無しで呼ばれたら、コンパイルしているクラスの名前のハッシュへの
+リファレンスを返します。
+クラスメソッドとして呼ばれたら、その呼び出したクラスの名前のハッシュへの
+リファレンスを返します。
+オブジェクトメソッドとして呼ばれたら、この関数は、オブジェクトが
+属している、どんなクラスでも、クラスの名前のハッシュへの
+リファレンスを返します。
+
+ package Some_Class;
+ use strict;
+
+ our %Some_Class = ( # our() is new to perl5.6
+ CData1 => "",
+ CData2 => "",
+ );
+
+=begin original
+
+ # tri-natured: function, class method, or object method
+ sub _classobj {
+ my $obclass = shift || __PACKAGE__;
+ my $class = ref($obclass) || $obclass;
+ no strict "refs"; # to convert sym ref to real one
+ return \%$class;
+ }
+
+=end original
+
+ # tri-natured: function, class method, or object method
+ sub _classobj {
+ my $obclass = shift || __PACKAGE__;
+ my $class = ref($obclass) || $obclass;
+ no strict "refs"; # シンボリックリファレンスを本当のリファレンスへと変換する
+ return \%$class;
+ }
+
+=begin original
+
+ for my $datum (keys %{ _classobj() } ) {
+ # turn off strict refs so that we can
+ # register a method in the symbol table
+ no strict "refs";
+ *$datum = sub {
+ use strict "refs";
+ my $self = shift->_classobj();
+ $self->{$datum} = shift if @_;
+ return $self->{$datum};
+ }
+ }
+
+=end original
+
+ for my $datum (keys %{ _classobj() } ) {
+ # strict refs をオフにするので、
+ # シンボルテーブルにメソッドを登録できます。
+ no strict "refs";
+ *$datum = sub {
+ use strict "refs";
+ my $self = shift->_classobj();
+ $self->{$datum} = shift if @_;
+ return $self->{$datum};
+ }
+ }
+
+=head2 Indirect References to Class Data
+
+(間接的なクラスデータへのリファレンス)
+
+=begin original
+
+A reasonably common strategy for handling class attributes is to store
+a reference to each package variable on the object itself. This is
+a strategy you've probably seen before, such as in L<perltoot> and
+L<perlbot>, but there may be variations in the example below that you
+haven't thought of before.
+
+=end original
+
+クラス属性を取り扱うの合理的で一般的な作戦とは、
+オブジェクトそれ自身で、それぞれのパッケージ変数へのリファレンスを
+格納することです。
+これは、おそらく既にみた作戦です。
+L<perltoot> や、L<perlbot> にあるようなものです。
+ですが、まだ考えたことのないようなバリエーションの例が下にあります。
+
+ package Some_Class;
+ our($CData1, $CData2); # our() is new to perl5.6
+
+ sub new {
+ my $obclass = shift;
+ return bless my $self = {
+ ObData1 => "",
+ ObData2 => "",
+ CData1 => \$CData1,
+ CData2 => \$CData2,
+ } => (ref $obclass || $obclass);
+ }
+
+ sub ObData1 {
+ my $self = shift;
+ $self->{ObData1} = shift if @_;
+ return $self->{ObData1};
+ }
+
+ sub ObData2 {
+ my $self = shift;
+ $self->{ObData2} = shift if @_;
+ return $self->{ObData2};
+ }
+
+ sub CData1 {
+ my $self = shift;
+ my $dataref = ref $self
+ ? $self->{CData1}
+ : \$CData1;
+ $$dataref = shift if @_;
+ return $$dataref;
+ }
+
+ sub CData2 {
+ my $self = shift;
+ my $dataref = ref $self
+ ? $self->{CData2}
+ : \$CData2;
+ $$dataref = shift if @_;
+ return $$dataref;
+ }
+
+=begin original
+
+As written above, a derived class will inherit these methods, which
+will consequently access package variables in the base class's package.
+This is not necessarily expected behavior in all circumstances. Here's an
+example that uses a variable meta-object, taking care to access the
+proper package's data.
+
+=end original
+
+上に書いたように、派生クラスが、これらのメソッドを継承します。
+これらのメソッドは基底クラスのパッケージのパッケージ変数に持続的に
+アクセスします。
+このことは、全ての状況で、必要とされ、期待された振る舞いではありません。
+変数、メタオブジェクトを使う例があります。
+適当なパッケージのデータへのアクセスを解決します。
+
+ package Some_Class;
+ use strict;
+
+ our %Some_Class = ( # our() is new to perl5.6
+ CData1 => "",
+ CData2 => "",
+ );
+
+ sub _classobj {
+ my $self = shift;
+ my $class = ref($self) || $self;
+ no strict "refs";
+ # get (hard) ref to eponymous meta-object
+ return \%$class;
+ }
+
+ sub new {
+ my $obclass = shift;
+ my $classobj = $obclass->_classobj();
+ bless my $self = {
+ ObData1 => "",
+ ObData2 => "",
+ CData1 => \$classobj->{CData1},
+ CData2 => \$classobj->{CData2},
+ } => (ref $obclass || $obclass);
+ return $self;
+ }
+
+ sub ObData1 {
+ my $self = shift;
+ $self->{ObData1} = shift if @_;
+ return $self->{ObData1};
+ }
+
+ sub ObData2 {
+ my $self = shift;
+ $self->{ObData2} = shift if @_;
+ return $self->{ObData2};
+ }
+
+ sub CData1 {
+ my $self = shift;
+ $self = $self->_classobj() unless ref $self;
+ my $dataref = $self->{CData1};
+ $$dataref = shift if @_;
+ return $$dataref;
+ }
+
+ sub CData2 {
+ my $self = shift;
+ $self = $self->_classobj() unless ref $self;
+ my $dataref = $self->{CData2};
+ $$dataref = shift if @_;
+ return $$dataref;
+ }
+
+=begin original
+
+Not only are we now strict refs clean, using an eponymous meta-object
+seems to make the code cleaner. Unlike the previous version, this one
+does something interesting in the face of inheritance: it accesses the
+class meta-object in the invoking class instead of the one into which
+the method was initially compiled.
+
+=end original
+
+今、strict ref を取り除いているだけでなく、クラスの名前のメタオブジェクトを
+使って、コードクリーナーを作っているようです。
+前のバージョンとは違い、これは、継承に直面すると、ちょっと面白いことを
+します：
+これは、呼び出しているクラスの、クラスのメタオブジェクトにアクセスします。
+メソッドが最初にコンパイルされたクラスではありません。
+
+
+=begin original
+
+You can easily access data in the class meta-object, making
+it easy to dump the complete class state using an external mechanism such
+as when debugging or implementing a persistent class. This works because
+the class meta-object is a package variable, has a well-known name, and
+clusters all its data together. (Transparent persistence
+is not always feasible, but it's certainly an appealing idea.)
+
+=end original
+
+クラスのメタオブジェクトのデータに簡単にアクセスすることが出来ます。
+デバッギングや、永続クラスを実装するときのような外部のメカニズムを使って、
+完全なクラスの状態を簡単にダンプできます。
+このように働くのは、クラスのメタオブジェクトがパッケージ変数であり、
+よく知られた名前を持ち、全てのそのデータを一緒にまとめているからです。
+(透過的な永続生は常に適しているわけではありませんが、魅力的なアイデアで
+あるのは確かです。)
+
+=begin original
+
+There's still no check that object accessor methods have not been
+invoked on a class name. If strict ref checking is enabled, you'd
+blow up. If not, then you get the eponymous meta-object. What you do
+with--or about--this is up to you. The next two sections demonstrate
+innovative uses for this powerful feature.
+
+=end original
+
+まだ、オブジェクトのアクセサメソッドがクラスの名前で呼び出されていないことを
+チェックしていません。
+strict ref のチェックが有効なら、壊れます。
+そうでなければ、クラスの名前のメタオブジェクトを得ます。
+それを我慢するか、なんとかするかは、あなた次第です。
+次の 2 つのセクションで、この強力な特徴の画期的な利用法を、
+デモンストレーションします。
+
+=head2 Monadic Classes
+
+(一価のクラス)
+
+=begin original
+
+Some of the standard modules shipped with Perl provide class interfaces
+without any attribute methods whatsoever. The most commonly used module
+not numbered amongst the pragmata, the Exporter module, is a class with
+neither constructors nor attributes. Its job is simply to provide a
+standard interface for modules wishing to export part of their namespace
+into that of their caller. Modules use the Exporter's &import method by
+setting their inheritance list in their package's @ISA array to mention
+"Exporter". But class Exporter provides no constructor, so you can't
+have several instances of the class. In fact, you can't have any--it
+just doesn't make any sense. All you get is its methods. Its interface
+contains no statefulness, so state data is wholly superfluous.
+
+=end original
+
+Perlに載っている標準モジュールには、何の属性メソッドも一切ない、
+クラスインターフェースを提供しているものがいくつかあります。
+もっとも普通に使われているモジュールは、プラグマを数にいれなければ、
+Exporter モジュールです。
+このモジュールは、コンストラクタも、属性もないクラスです。
+Exporter の仕事は、単純に、モジュールが呼び出しもとに自分の名前空間の一部を
+エクスポートする、
+標準のインターフェースを提供することです。
+モジュールは 、それぞれのモジュールの@ISA配列に継承のリストをセットすることで、
+Exporter の &import メソッドを使い、"Exporter" に記載します。
+ですが、クラスの Exporter には、コンストラクタがありません。
+そのため、複数のクラスのインスタンスを持つことが出来ません。
+実際に、一つももてません -- 全く意味をなさない。
+あなたが得る全てのものは、そのメソッドです、
+そのインターフェースには、なんの状態も含みません。
+ですので、状態のデータはまったく不要なのです。
+
+=begin original
+
+Another sort of class that pops up from time to time is one that supports
+a unique instance. Such classes are called I<monadic classes>, or less
+formally, I<singletons> or I<highlander classes>.
+
+=end original
+
+別の種類のクラスで、時間から時間までを取得するモジュールは、
+単一のインスタンスをサポートするものです。
+このようなクラスは I<一価のクラス> と呼ばれます。
+または、あまり正式ではありませんが、I<singletons> とか、
+I<highlander classes>と 呼ばれます。
+
+=begin original
+
+If a class is monadic, where do you store its state, that is,
+its attributes? How do you make sure that there's never more than
+one instance? While you could merely use a slew of package variables,
+it's a lot cleaner to use the eponymously named hash. Here's a complete
+example of a monadic class:
+
+=end original
+
+クラスが一価であれば、その状態、すなわち、属性をどこに格納するのでしょう。
+一つのインスタンスより他にはないと、どのように確認するでしょうか？
+たくさんのパッケージ変数を単に使うこともできますが、
+クラスの名前のハッシュを使うクリーナーを使うことも非常にあります。
+一価のクラスの完全な例です:
+
+ package Cosmos;
+ %Cosmos = ();
+
+=begin original
+
+ # accessor method for "name" attribute
+ sub name {
+ my $self = shift;
+ $self->{name} = shift if @_;
+ return $self->{name};
+ }
+
+=end original
+
+ # "name" 属性のアクセサメソッド
+ sub name {
+ my $self = shift;
+ $self->{name} = shift if @_;
+ return $self->{name};
+ }
+
+=begin original
+
+ # read-only accessor method for "birthday" attribute
+ sub birthday {
+ my $self = shift;
+ die "can't reset birthday" if @_; # XXX: croak() is better
+ return $self->{birthday};
+ }
+
+=end original
+
+ # "birthday" 属性の読み込みのみのアクセサメソッド
+ sub birthday {
+ my $self = shift;
+ die "can't reset birthday" if @_; # XXX: croak() is better
+ return $self->{birthday};
+ }
+
+=begin original
+
+ # accessor method for "stars" attribute
+ sub stars {
+ my $self = shift;
+ $self->{stars} = shift if @_;
+ return $self->{stars};
+ }
+
+=end original
+
+ # "stars" 属性のアクセサメソッド
+ sub stars {
+ my $self = shift;
+ $self->{stars} = shift if @_;
+ return $self->{stars};
+ }
+
+=begin original
+
+ # oh my - one of our stars just went out!
+ sub supernova {
+ my $self = shift;
+ my $count = $self->stars();
+ $self->stars($count - 1) if $count > 0;
+ }
+
+=end original
+
+ # おや、まあ！ - 星が一つ、死んでしまった！
+ sub supernova {
+ my $self = shift;
+ my $count = $self->stars();
+ $self->stars($count - 1) if $count > 0;
+ }
+
+=begin original
+
+ # constructor/initializer method - fix by reboot
+ sub bigbang {
+ my $self = shift;
+ %$self = (
+ name => "the world according to tchrist",
+ birthday => time(),
+ stars => 0,
+ );
+ return $self; # yes, it's probably a class. SURPRISE!
+ }
+
+=end original
+
+ # コンストラクタ/イニシャライザ - リブートで直される
+ sub bigbang {
+ my $self = shift;
+ %$self = (
+ name => "the world according to tchrist",
+ birthday => time(),
+ stars => 0,
+ );
+ return $self; # はい、おそらくクラスです。
+びっくり！
+ }
+
+=begin original
+
+ # After the class is compiled, but before any use or require
+ # returns, we start off the universe with a bang.
+ __PACKAGE__ -> bigbang();
+
+=end original
+
+ # クラスがコンパイルされた後、ですが、use も require も戻る前、
+ # バンとともに、宇宙が動き始めます。
+ __PACKAGE__ -> bigbang();
+
+=begin original
+
+Hold on, that doesn't look like anything special. Those attribute
+accessors look no different than they would if this were a regular class
+instead of a monadic one. The crux of the matter is there's nothing
+that says that $self must hold a reference to a blessed object. It merely
+has to be something you can invoke methods on. Here the package name
+itself, Cosmos, works as an object. Look at the &supernova method. Is that
+a class method or an object method? The answer is that static analysis
+cannot reveal the answer. Perl doesn't care, and neither should you.
+In the three attribute methods, C<%$self> is really accessing the %Cosmos
+package variable.
+
+=end original
+
+そのままでいてください。
+何も特別なようにはみえません。
+これらの属性アクセサは一価のクラスであるか、普通のクラスであるかで、
+することは何も違いません。
+ここでの最重要ポイントは $self がオブジェクトに bless されたリファレンスを
+持たなければならないとは言わないところです。
+単に、メソッドを呼ぶことができれば、何でもいいのです。
+パッケージの名前自身、Cosmos でも、オブジェクトのように働きます。
+&supernova メソッドをみてください。
+これは、クラスメソッドか、オブジェクトメソッドでしょうか？
+その答えは、静的な解析ではその答えを知らせることはできないということです。
+Perlは、気にしませんし、あなたも気にしないべきです。
+3 つの属性メソッドで、C<%$self> は、実際は、%Cosmos パッケージ変数に
+アクセスしています。
+
+=begin original
+
+If like Stephen Hawking, you posit the existence of multiple, sequential,
+and unrelated universes, then you can invoke the &bigbang method yourself
+at any time to start everything all over again. You might think of
+&bigbang as more of an initializer than a constructor, since the function
+doesn't allocate new memory; it only initializes what's already there.
+But like any other constructor, it does return a scalar value to use
+for later method invocations.
+
+=end original
+
+ステファン・ホーキングのように、複数の、連続の、関係のない宇宙の存在を
+仮定するなら、
+&bigbang メソッドを自分で呼び、いつでも、そっくり再び、全てを
+始めることができます。
+&bigbang を、コンストラクタよりも、もっとイニシャライザとして、
+考えているかもしれません。
+&bigbang は、新たのメモリを割り当てません、すなわち、&bingbang は、既に
+そこにあるものを、初期化するだけというために。
+ですが、他のどんなコンストラクタと同じように、後のメソッド呼び出しに
+使うために、スカラ値をを返します。
+
+=begin original
+
+Imagine that some day in the future, you decide that one universe just
+isn't enough. You could write a new class from scratch, but you already
+have an existing class that does what you want--except that it's monadic,
+and you want more than just one cosmos.
+
+=end original
+
+将来のいつかに、一つの宇宙では十分ではないと、決心したとしましょう。
+スクラッチから新しいクラスを書くこともできますが、
+既存のクラスがあります -- 一価であることを除いて、望むクラスがあり、
+しかも、ただ、2 つ以上の宇宙が欲しいだけです。
+
+=begin original
+
+That's what code reuse via subclassing is all about. Look how short
+the new code is:
+
+=end original
+
+サブクラスでコードの再利用することが全てです。
+新しいコードがどのくらい短いか、見てみましょう。
+
+ package Multiverse;
+ use Cosmos;
+ @ISA = qw(Cosmos);
+
+ sub new {
+ my $protoverse = shift;
+ my $class = ref($protoverse) || $protoverse;
+ my $self = {};
+ return bless($self, $class)->bigbang();
+ }
+ 1;
+
+=begin original
+
+Because we were careful to be good little creators when we designed our
+Cosmos class, we can now reuse it without touching a single line of code
+when it comes time to write our Multiverse class. The same code that
+worked when invoked as a class method continues to work perfectly well
+when invoked against separate instances of a derived class.
+
+=end original
+
+Cosmosクラスを設計している時に、慎重であり、良い小さなクリエータであったので、
+Multiverse クラスを書く際に、コードの一行もいじらないで、Cosmos クラスを
+再利用することができます。
+クラスメソッドとして呼ばれたときに動く同じコードが派生クラスの個々の
+インスタンスから呼ばれても、完全に、うまく、動き続けます。
+
+=begin original
+
+The astonishing thing about the Cosmos class above is that the value
+returned by the &bigbang "constructor" is not a reference to a blessed
+object at all. It's just the class's own name. A class name is, for
+virtually all intents and purposes, a perfectly acceptable object.
+It has state, behavior, and identity, the three crucial components
+of an object system. It even manifests inheritance, polymorphism,
+and encapsulation. And what more can you ask of an object?
+
+=end original
+
+上にあげた、Cosmos クラスでびっくりするのは、&bigbang "コンストラクタ" が
+返す値が、まったく、bless されたオブジェクトへのリファレンスではないことです。
+&bigbang コンストラクタが返す値は、クラス自身の名前です。
+クラス名は、全ての目的と手段にとって、実質的に、完全に条件を満たしている
+オブジェクトです。
+状態、振舞、同一性、3つの、オブジェクトシステムの重大な構成要素が、
+クラス名にはあります。
+クラス名は、継承、ポリモルフィズム、カプセル化さえも明らかにします。
+オブジェクトにこれ以上何を要求できますか？
+
+=begin original
+
+To understand object orientation in Perl, it's important to recognize the
+unification of what other programming languages might think of as class
+methods and object methods into just plain methods. "Class methods"
+and "object methods" are distinct only in the compartmentalizing mind
+of the Perl programmer, not in the Perl language itself.
+
+=end original
+
+Perl でオブジェクト指向を理解するために、他のプログラミング言語が
+クラスメソッドとオブジェクトメソッドについて考えていることを、ただの単純な
+メソッドに統一することを認識するのが重要です。
+"クラスメソッド"と、"オブジェクトメソッド"は、Perl プログラマが心の中で
+区切っているだけで、Perl 言語それ自身の中では、区切られていません。
+
+=begin original
+
+Along those same lines, a constructor is nothing special either, which
+is one reason why Perl has no pre-ordained name for them. "Constructor"
+is just an informal term loosely used to describe a method that returns
+a scalar value that you can make further method calls against. So long
+as it's either a class name or an object reference, that's good enough.
+It doesn't even have to be a reference to a brand new object.
+
+=end original
+
+これらの同じ行の間で、コンストラクタは、何も特別なものではありません。
+Perlには、それらの行に、神によって定められている名前はないのがその理由です。
+"コンストラクタ"は公式ではない述語であり、後でメソッドを呼ぶことのできる
+スカラー値を返すメソッドを説明するのを使います。
+クラス名もオブジェクトリファレンスでありさえすれば、十分、上等です。
+おろしたてのオブジェクトがリファレンスである必要さえないのです。
+
+=begin original
+
+You can have as many--or as few--constructors as you want, and you can
+name them whatever you care to. Blindly and obediently using new()
+for each and every constructor you ever write is to speak Perl with
+such a severe C++ accent that you do a disservice to both languages.
+There's no reason to insist that each class have but one constructor,
+or that a constructor be named new(), or that a constructor be
+used solely as a class method and not an object method.
+
+=end original
+
+自分が望むのと同じくらい、多くの -- または、ほとんどない -- 、コンストラクタを
+持つことができますし、自分がしたいように何でも名前を付けることができます。
+やみくもに、素直に、いままで書いた、ありとあらゆるコンストラクタに、
+new() を使うことは、両方の言語にひどい仕打をする、厳格な C++ の
+アクセントのようなもので、Perl を喋ることです。
+それぞれのクラスに一つのコンストラクタがあるとか、または、コンストラクタは
+new() と名付けられるとか、コンストラクタはオブジェクトメソッドではなく、
+ただクラスメソッドとして使われるとか、そういうことを強く主張する理由は
+まったくありません。
+
+=begin original
+
+The next section shows how useful it can be to further distance ourselves
+from any formal distinction between class method calls and object method
+calls, both in constructors and in accessor methods.
+
+=end original
+
+次のセクションでは、コンストラクタとアクセサメソッドの両方で、
+クラスメソッドとオブジェクトメソッドの呼び出しとの間で、
+正式な区別から、我々自身がさらに遠くまでありうるということが、
+どれくらい有益であるかを示します。
+
+=head2 Translucent Attributes
+
+(半透明の属性)
+
+=begin original
+
+A package's eponymous hash can be used for more than just containing
+per-class, global state data. It can also serve as a sort of template
+containing default settings for object attributes. These default
+settings can then be used in constructors for initialization of a
+particular object. The class's eponymous hash can also be used to
+implement I<translucent attributes>. A translucent attribute is one
+that has a class-wide default. Each object can set its own value for the
+attribute, in which case C<< $object->attribute() >> returns that value.
+But if no value has been set, then C<< $object->attribute() >> returns
+the class-wide default.
+
+=end original
+
+パッケージの名前のハッシュはクラスごとに、グローバルな状態のデータを
+ただ持つ以上に、使うことができます。
+オブジェクト属性のデフォルトの設定を持つ、一種のテンプレートとしての役目も
+出来ます。
+これらのデフォルトの設定は、コンストラクタで、特定のオブジェクトの初期化の
+ために使うことができます。
+クラスの名前のハッシュは、I<半透明の属性>を実装するのにも使うことも出来ます。
+半透明の属性とは、クラスワイドのデフォルトを持つ属性です。
+それぞれのオブジェクトは属性にそれ自身の値をセットできます、
+そこでは、C<< $object->attribute() >> で、値を返します。
+ですが、値がまだセットされていなければ、C<< $object->attribute() >> は、
+クラスワイドのデフォルトを返します。
+
+=begin original
+
+We'll apply something of a copy-on-write approach to these translucent
+attributes. If you're just fetching values from them, you get
+translucency. But if you store a new value to them, that new value is
+set on the current object. On the other hand, if you use the class as
+an object and store the attribute value directly on the class, then the
+meta-object's value changes, and later fetch operations on objects with
+uninitialized values for those attributes will retrieve the meta-object's
+new values. Objects with their own initialized values, however, won't
+see any change.
+
+=end original
+
+これらの半透明の属性に コピー・オン・ライトのアプローチの何かを
+適用するでしょう。
+これらの属性からただ、値を取りだしているならば、半透明性を得ます。
+ですが、これらの属性に新しい値を蓄えるなら、新しい値は現在のオブジェクトに
+セットされます。
+他方で、クラスをオブジェクトとして使い、直接にクラスで属性値を蓄えるなら、
+メタオブジェクトの値が変更し、その後で、それらの属性が初期化されていない値で
+オブジェクトで作業を取ると、メタオブジェクトの新しい値を
+取り出すでしょう(訳註:訳怪しい)。
+
+=begin original
+
+Let's look at some concrete examples of using these properties before we
+show how to implement them. Suppose that a class named Some_Class
+had a translucent data attribute called "color". First you set the color
+in the meta-object, then you create three objects using a constructor
+that happens to be named &spawn.
+
+=end original
+
+どのように実装するかを見せる前に、これらのプロパティを使う、具体的な例を
+見てみましょう。
+Some_Class という名前のクラスに、"color" という半透明のクラス属性が
+あるとします。
+まず、meta-object のカラーをセットします。
+それから、コンストラクタを使って、3つ のオブジェクトをつくります。
+コンストラクタは、たまたま &spawn という名前です。
+
+ use Vermin;
+ Vermin->color("vermilion");
+
+ $ob1 = Vermin->spawn(); # so that's where Jedi come from
+ $ob2 = Vermin->spawn();
+ $ob3 = Vermin->spawn();
+
+ print $obj3->color(); # prints "vermilion"
+
+=begin original
+
+Each of these objects' colors is now "vermilion", because that's the
+meta-object's value for that attribute, and these objects do not have
+individual color values set.
+
+=end original
+
+それぞれのオブジェクトの色は、現在、"vermilion(朱色)" です。
+メタオブジェクトのその属性の値がそれであり、それぞれのオブジェクトに個別の
+色の値がセットされていないからです。
+
+=begin original
+
+Changing the attribute on one object has no effect on other objects
+previously created.
+
+=end original
+
+あるオブジェクトの属性を変更しても、先に作られた他のオブジェクトの値には
+影響しません。
+
+ $ob3->color("chartreuse");
+ print $ob3->color(); # prints "chartreuse"
+ print $ob1->color(); # prints "vermilion", translucently
+
+=begin original
+
+If you now use $ob3 to spawn off another object, the new object will
+take the color its parent held, which now happens to be "chartreuse".
+That's because the constructor uses the invoking object as its template
+for initializing attributes. When that invoking object is the
+class name, the object used as a template is the eponymous meta-object.
+When the invoking object is a reference to an instantiated object, the
+&spawn constructor uses that existing object as a template.
+
+=end original
+
+$ob3 を使い、他のオブジェクトを産んでみると、新しいオブジェクトは、
+その親が持っている色を取るでしょう。
+今は、たまたま、"chartreuse(淡黄緑色)" になるでしょう。
+コンストラクタが、初期化の属性のテンプレートとして、呼び出したオブジェクトを
+使うからです。
+呼び出すオブジェクトがクラス名であれば、オブジェクトは、クラスの
+メタオブジェクトを参照します。
+呼び出すオブジェクトが説明されたオブジェクトへのリファレンスであれば、
+&spawn コンストラクタは、テンプレートとして、存在するオブジェクトを使います。
+
+ $ob4 = $ob3->spawn(); # $ob3 now template, not %Vermin
+ print $ob4->color(); # prints "chartreuse"
+
+=begin original
+
+Any actual values set on the template object will be copied to the
+new object. But attributes undefined in the template object, being
+translucent, will remain undefined and consequently translucent in the
+new one as well.
+
+=end original
+
+テンプレートオブジェクトにセットされる実際の値は、どんなものも、
+新しいオブジェクトにコピーされます。
+ですが、テンプレートオブジェクトに未定義の属性は、半透明になり、未定義の
+ままとなり、その結果、新しいものも同様に半透明です。
+
+=begin original
+
+Now let's change the color attribute on the entire class:
+
+=end original
+
+今度は、クラス全体のcolor属性を変更しましょう:
+
+ Vermin->color("azure");
+ print $ob1->color(); # prints "azure"
+ print $ob2->color(); # prints "azure"
+ print $ob3->color(); # prints "chartreuse"
+ print $ob4->color(); # prints "chartreuse"
+
+=begin original
+
+That color change took effect only in the first pair of objects, which
+were still translucently accessing the meta-object's values. The second
+pair had per-object initialized colors, and so didn't change.
+
+=end original
+
+この色の変更はオブジェクトの最初の2つにのみ、影響します。
+この 2 つは、まだ、半透明で、メタオブジェクトの値にアクセスします。
+後の 2 つは、オブジェクトごとに、初期化された色がありました。
+そのため、変更されません。
+
+=begin original
+
+One important question remains. Changes to the meta-object are reflected
+in translucent attributes in the entire class, but what about
+changes to discrete objects? If you change the color of $ob3, does the
+value of $ob4 see that change? Or vice-versa. If you change the color
+of $ob4, does then the value of $ob3 shift?
+
+=end original
+
+一つ、重要な疑問があります。
+メタオブジェクトの値を変えることは、クラス全体の半透明の属性に反映されます。
+ですが、オブジェクトを絶やす変更はどうでしょうか？
+$ob3 の色を変更したら、$ob4 にはその変更がわかるでしょうか？
+また、逆の場合も同じく。
+もし、$ob4 の色を変更したら、$ob4 の値は変わるでしょうか？
+
+ $ob3->color("amethyst");
+ print $ob3->color(); # prints "amethyst"
+ print $ob4->color(); # hmm: "chartreuse" or "amethyst"?
+
+=begin original
+
+While one could argue that in certain rare cases it should, let's not
+do that. Good taste aside, we want the answer to the question posed in
+the comment above to be "chartreuse", not "amethyst". So we'll treat
+these attributes similar to the way process attributes like environment
+variables, user and group IDs, or the current working directory are
+treated across a fork(). You can change only yourself, but you will see
+those changes reflected in your unspawned children. Changes to one object
+will propagate neither up to the parent nor down to any existing child objects.
+Those objects made later, however, will see the changes.
+
+=end original
+
+While one could argue that .. 確かにまれなケースでは、そうすべきですが、
+そうしないでおきましょう。
+Good taste aside, "chartreuse" "amethyst"
+環境変数のように属性を処理するのと似たような方法で、それらの属性を扱いましょう。
+ユーザやグループや現在のワーキングディレクトリは、fork() を超えて、扱われます。
+自分自身のみ変更できても、それらの変更が、産まれない子に反映するのが
+わかるでしょう。
+一つのオブジェクトの変更は、親にまで、さかのぼり、存在する子にまで下って、
+オブジェクトに伝播します。
+これらのオブジェクトは後で作られても、変更がわかるでしょう。
+(TBT)
+
+=begin original
+
+If you have an object with an actual attribute value, and you want to
+make that object's attribute value translucent again, what do you do?
+Let's design the class so that when you invoke an accessor method with
+C<undef> as its argument, that attribute returns to translucency.
+
+=end original
+
+実際の属性値でオブジェクトを持ち、オブジェクトの属性値を再び半透明に
+したければ、どうしましょうか？
+クラスを、その引数に、C<undef> でアクセサメソッドを呼ぶとき、
+その属性は半透明性に
+(TBT)
+
+ $ob4->color(undef); # back to "azure"
+
+=begin original
+
+Here's a complete implementation of Vermin as described above.
+
+=end original
+
+上で説明した Vermin の完全な実装です。
+
+ package Vermin;
+
+ # here's the class meta-object, eponymously named.
+ # it holds all class attributes, and also all instance attributes
+ # so the latter can be used for both initialization
+ # and translucency.
+
+ our %Vermin = ( # our() is new to perl5.6
+ PopCount => 0, # capital for class attributes
+ color => "beige", # small for instance attributes
+ );
+
+ # constructor method
+ # invoked as class method or object method
+ sub spawn {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ my $self = {};
+ bless($self, $class);
+ $class->{PopCount}++;
+ # init fields from invoking object, or omit if
+ # invoking object is the class to provide translucency
+ %$self = %$obclass if ref $obclass;
+ return $self;
+ }
+
+ # translucent accessor for "color" attribute
+ # invoked as class method or object method
+ sub color {
+ my $self = shift;
+ my $class = ref($self) || $self;
+
+ # handle class invocation
+ unless (ref $self) {
+ $class->{color} = shift if @_;
+ return $class->{color}
+ }
+
+ # handle object invocation
+ $self->{color} = shift if @_;
+ if (defined $self->{color}) { # not exists!
+ return $self->{color};
+ } else {
+ return $class->{color};
+ }
+ }
+
+ # accessor for "PopCount" class attribute
+ # invoked as class method or object method
+ # but uses object solely to locate meta-object
+ sub population {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ return $class->{PopCount};
+ }
+
+ # instance destructor
+ # invoked only as object method
+ sub DESTROY {
+ my $self = shift;
+ my $class = ref $self;
+ $class->{PopCount}--;
+ }
+
+=begin original
+
+Here are a couple of helper methods that might be convenient. They aren't
+accessor methods at all. They're used to detect accessibility of data
+attributes. The &is_translucent method determines whether a particular
+object attribute is coming from the meta-object. The &has_attribute
+method detects whether a class implements a particular property at all.
+It could also be used to distinguish undefined properties from non-existent
+ones.
+
+=end original
+
+2、3 の便利になるヘルパーメソッドがあります。
+これらは、まったく、アクセサメソッドではありません。
+データ属性のアクセシビリティを見つけるのに使われています。
+この &is_translucent メソッドは特別なオブジェクト属性が、
+メタオブジェクトからくるのかどうかを決めています。
+&has_attribute メソッドは、クラスが特別なプロパティを
+少しでも実装しているかどうかを見つけます。
+存在しないプロパティから、未定義のプロパティを区別するのにも、
+使われ得ます。
+
+ # detect whether an object attribute is translucent
+ # (typically?) invoked only as object method
+ sub is_translucent {
+ my($self, $attr) = @_;
+ return !defined $self->{$attr};
+ }
+
+ # test for presence of attribute in class
+ # invoked as class method or object method
+ sub has_attribute {
+ my($self, $attr) = @_;
+ my $class = ref($self) || $self;
+ return exists $class->{$attr};
+ }
+
+=begin original
+
+If you prefer to install your accessors more generically, you can make
+use of the upper-case versus lower-case convention to register into the
+package appropriate methods cloned from generic closures.
+
+=end original
+
+より一般的に、アクセサをインストールしたいなら、
+パッケージに、一般のクロージャからクローニングされた適切なメソッドを
+登録するのに、大文字対小文字の慣習を利用することができます。
+
+ for my $datum (keys %{ +__PACKAGE__ }) {
+ *$datum = ($datum =~ /^[A-Z]/)
+ ? sub { # install class accessor
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ return $class->{$datum};
+ }
+ : sub { # install translucent accessor
+ my $self = shift;
+ my $class = ref($self) || $self;
+ unless (ref $self) {
+ $class->{$datum} = shift if @_;
+ return $class->{$datum}
+ }
+ $self->{$datum} = shift if @_;
+ return defined $self->{$datum}
+ ? $self -> {$datum}
+ : $class -> {$datum}
+ }
+ }
+
+=begin original
+
+Translations of this closure-based approach into C++, Java, and Python
+have been left as exercises for the reader. Be sure to send us mail as
+soon as you're done.
+
+=end original
+
+このクロージャベースのアプローチを、C++、Java、Python へ、
+転換するのは、読者の課題として残しておきます。
+できあがったらすぐに、きっと送ってくださいね。
+
+=head1 Class Data as Lexical Variables
+
+(レキシカル変数のクラスデータ)
+
+=head2 Privacy and Responsibility
+
+(プライバシーと責任)
+
+=begin original
+
+Unlike conventions used by some Perl programmers, in the previous
+examples, we didn't prefix the package variables used for class attributes
+with an underscore, nor did we do so for the names of the hash keys used
+for instance attributes. You don't need little markers on data names to
+suggest nominal privacy on attribute variables or hash keys, because these
+are B<already> notionally private! Outsiders have no business whatsoever
+playing with anything within a class save through the mediated access of
+its documented interface; in other words, through method invocations.
+And not even through just any method, either. Methods that begin with
+an underscore are traditionally considered off-limits outside the class.
+If outsiders skip the documented method interface to poke around the
+internals of your class and end up breaking something, that's not your
+fault--it's theirs.
+
+=end original
+
+Perlプログラマの幾人かに使われている慣習とは違い、先の例では、
+クラス属性に使われるパッケージ変数の前に、アンダースコアを付けていませんし、
+インスタンス属性に使われるハッシュキーの名前にも、そのようにしていません。
+データの名前に小さなマークをつけて、属性変数や、ハッシュのキーに、名目上の
+プライバシーを暗示する必要はありません。
+というのは、B<いつも> 概念的にプライベートだからです！
+部外者が、クラス内で何かをいじるかは、少しも気にしなく良いからです。
+そのドキュメントのインターフェースを通すのを除いて;言い換えると、メソッドの
+実行を通すのを除いて。
+And not even through just any method, either.
+メソッドアンダースコアで始まるメソッドは伝統的に、クラスの外側から立入禁止と
+考えられています。
+もし、部外者が、ドキュメントに書かれたメソッドインターフェースを読み飛ばして、
+クラスの内部をつつきまわして、何かを壊すことになっても、クラスの作者の
+落度ではありません。
+-- それは、そういうことをした部外者の落度です。
+(TBT)
+
+=begin original
+
+Perl believes in individual responsibility rather than mandated control.
+Perl respects you enough to let you choose your own preferred level of
+pain, or of pleasure. Perl believes that you are creative, intelligent,
+and capable of making your own decisions--and fully expects you to
+take complete responsibility for your own actions. In a perfect world,
+these admonitions alone would suffice, and everyone would be intelligent,
+responsible, happy, and creative. And careful. One probably shouldn't
+forget careful, and that's a good bit harder to expect. Even Einstein
+would take wrong turns by accident and end up lost in the wrong part
+of town.
+
+=end original
+
+Perl は、委任統治に指定されたコントロールよりもむしろ、個人の責務を
+信じています。
+Perl は十分にあなたを尊敬しているので、あなたに、自身にあったレベルの痛みや
+喜びを選択させます。
+Perl は、あなたが、創造的で、知性的で、自分自身で決定できると信じ、自身の
+行動に完全に責任を取れると期待しています。
+完全な世界では、このような勧告だけで十分でしょう。
+そして、全ての人が、知性的で、信頼でき、幸福で、創造的であるでしょう。
+そして、慎重であるでしょう。
+たぶんある人が慎重であることを忘れても、それは、かなり
+予測しがたいことでしょう。
+アインシュタインでさえ、うっかり曲がり間違えて、町の間違った地域で
+迷うことになった、
+(TBT)
+
+=begin original
+
+Some folks get the heebie-jeebies when they see package variables
+hanging out there for anyone to reach over and alter them. Some folks
+live in constant fear that someone somewhere might do something wicked.
+The solution to that problem is simply to fire the wicked, of course.
+But unfortunately, it's not as simple as all that. These cautious
+types are also afraid that they or others will do something not so
+much wicked as careless, whether by accident or out of desperation.
+If we fire everyone who ever gets careless, pretty soon there won't be
+anybody left to get any work done.
+
+=end original
+
+誰でも、パッケージ変数に、手が届き、変更できる、出入りできる、
+パッケージ変数に、とても神経質になる人もいます。
+誰かが、どこかで、 悪戯をすることに、不断に帯得ている人達です。
+この問題の解決は単純に、悪戯を押え込むことです、もちろん。
+ですが、不幸なことに、そなんに簡単ではありません。
+これらの警告タイプは、彼らや他の人々が、たまたまか、絶望の中からかどうか、
+注意なしにそんなにひどくない悪戯をするのにも恐れさせます。
+注意不足な人々みんなを解雇するするなら、そこには、すぐに、何かの仕事をする
+人は誰も居なくなるでしょう。
+
+=begin original
+
+Whether it's needless paranoia or sensible caution, this uneasiness can
+be a problem for some people. We can take the edge off their discomfort
+by providing the option of storing class attributes as lexical variables
+instead of as package variables. The my() operator is the source of
+all privacy in Perl, and it is a powerful form of privacy indeed.
+
+=end original
+
+それが、必要のないパラノイアか、賢明な警告かどうか、
+この不安は人によっては、問題になりえます。
+パッケージ変数の代わりにレキシカル変数に、クラス属性を蓄えるオプションを
+与えることで、そういう人たちの不安を和らげることができます。
+my() 演算子は Perl のすべてのプライバシーの源です。
+そして、my() は、プライバシーの強力な形です。
+実際に。
+
+=begin original
+
+It is widely perceived, and indeed has often been written, that Perl
+provides no data hiding, that it affords the class designer no privacy
+nor isolation, merely a rag-tag assortment of weak and unenforceable
+social conventions instead. This perception is demonstrably false and
+easily disproven. In the next section, we show how to implement forms
+of privacy that are far stronger than those provided in nearly any
+other object-oriented language.
+
+=end original
+
+次のことは、広く認められていますし、実際、よく書かれています。
+Perlは、データの隠蔽を提供しないし、
+Perlは、クラスの設計者にプライバシーも孤立も提供しません。
+単に、ぼろぎれの、弱点の詰め合わせであり、
+押しつけることの出来ない社会的慣習が代わりにあるだけです。
+この認識は、確実に間違いであり、ちっとも精査されていません。
+次のセクションでは、ほとんどのどんな他のオブジェクト指向言語で
+提供されているよりも、はるかに強力なプライバシーの形を実装するのを見せます。
+
+=head2 File-Scoped Lexicals
+
+(ファイルスコープのレキシカル変数)
+
+=begin original
+
+A lexical variable is visible only through the end of its static scope.
+That means that the only code able to access that variable is code
+residing textually below the my() operator through the end of its block
+if it has one, or through the end of the current file if it doesn't.
+
+=end original
+
+レキシカル変数はその静的なスコープの終りまででしか、見えません。
+このことは、ブロックがあればそのブロックの終りまでの、ブロックがなければ
+現在のファイルの終りまでの、my() 演算子の下にあるテキストに存在する
+コードだけが、この変数にアクセス出来る唯一のコードです。
+
+=begin original
+
+Starting again with our simplest example given at the start of this
+document, we replace our() variables with my() versions.
+
+=end original
+
+このドキュメントの最初にあった、最も単純な例で始めましょう。
+our() 変数を my() バージョンで置き換えます。
+
+ package Some_Class;
+ my($CData1, $CData2); # file scope, not in any package
+ sub CData1 {
+ shift; # XXX: ignore calling class/object
+ $CData1 = shift if @_;
+ return $CData1;
+ }
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ $CData2 = shift if @_;
+ return $CData2;
+ }
+
+=begin original
+
+So much for that old $Some_Class::CData1 package variable and its brethren!
+Those are gone now, replaced with lexicals. No one outside the
+scope can reach in and alter the class state without resorting to the
+documented interface. Not even subclasses or superclasses of
+this one have unmediated access to $CData1. They have to invoke the &CData1
+method against Some_Class or an instance thereof, just like anybody else.
+
+=end original
+
+あの古い、$Some_Class::CData1 パッケージ変数とその仲間については、
+これだけにしておきます！
+それらは、今や過ぎさって、レキシカル変数に置き換えられました。
+スコープの外側にいる誰も、ドキュメントに書かれたインターフェースの手段以外に、
+クラスの状態に影響を及ぼせませんし、変更も出来ません。
+このサブクラスやスーパークラスでさえ、$CData1 へアクセスを仲介しません。
+Some_Class か、そのインスタンスか、他の似たようなもので、
+&CData1 メソッドを呼ぶ必要があります。
+
+=begin original
+
+To be scrupulously honest, that last statement assumes you haven't packed
+several classes together into the same file scope, nor strewn your class
+implementation across several different files. Accessibility of those
+variables is based uniquely on the static file scope. It has nothing to
+do with the package. That means that code in a different file but
+the same package (class) could not access those variables, yet code in the
+same file but a different package (class) could. There are sound reasons
+why we usually suggest a one-to-one mapping between files and packages
+and modules and classes. You don't have to stick to this suggestion if
+you really know what you're doing, but you're apt to confuse yourself
+otherwise, especially at first.
+
+=end original
+
+ものすごく正直になれば、最後のステートメントは、同じファイルスコープに、
+複数のクラスを一緒にパックしないし、複数の違うファイルにまたがって、クラスの
+実装ばらまきもしないと想定するでしょう。
+これらの変数のアクセシビリティは、静的なファイルスコープでユニークに
+ベースにされています。
+
+=begin original
+
+If you'd like to aggregate your class attributes into one lexically scoped,
+composite structure, you're perfectly free to do so.
+
+=end original
+
+クラス属性を 1 つのレキシカルスコープの変数に集約し、構造体を作りたければ、
+そうするのは、完全に自由です。
+
+ package Some_Class;
+ my %ClassData = (
+ CData1 => "",
+ CData2 => "",
+ );
+ sub CData1 {
+ shift; # XXX: ignore calling class/object
+ $ClassData{CData1} = shift if @_;
+ return $ClassData{CData1};
+ }
+ sub CData2 {
+ shift; # XXX: ignore calling class/object
+ $ClassData{CData2} = shift if @_;
+ return $ClassData{CData2};
+ }
+
+=begin original
+
+To make this more scalable as other class attributes are added, we can
+again register closures into the package symbol table to create accessor
+methods for them.
+
+=end original
+
+他のクラス属性を加えるように、より拡張性をもたせたければ、
+再び、パッケージのシンボルテーブルにクロージャを登録し、
+それらのためのアクセスメソッドを作れます。
+
+ package Some_Class;
+ my %ClassData = (
+ CData1 => "",
+ CData2 => "",
+ );
+ for my $datum (keys %ClassData) {
+ no strict "refs";
+ *$datum = sub {
+ shift; # XXX: ignore calling class/object
+ $ClassData{$datum} = shift if @_;
+ return $ClassData{$datum};
+ };
+ }
+
+=begin original
+
+Requiring even your own class to use accessor methods like anybody else is
+probably a good thing. But demanding and expecting that everyone else,
+be they subclass or superclass, friend or foe, will all come to your
+object through mediation is more than just a good idea. It's absolutely
+critical to the model. Let there be in your mind no such thing as
+"public" data, nor even "protected" data, which is a seductive but
+ultimately destructive notion. Both will come back to bite at you.
+That's because as soon as you take that first step out of the solid
+position in which all state is considered completely private, save from the
+perspective of its own accessor methods, you have violated the envelope.
+And, having pierced that encapsulating envelope, you shall doubtless
+someday pay the price when future changes in the implementation break
+unrelated code. Considering that avoiding this infelicitous outcome was
+precisely why you consented to suffer the slings and arrows of obsequious
+abstraction by turning to object orientation in the first place, such
+breakage seems unfortunate in the extreme.
+
+=end original
+
+何か他のようなアクセサメソッドを使う自分自身のクラスを必要とすることは、
+おそらく良い事です。ですが、他のもの全て、サブクラス、スーパークラス、
+敵味方、全てが、仲介を通してあなたのオブジェクトにくるのを、
+要求したり、予期したりすることは、良い考えを超えるものです。
+これは、そのモデルにとって全く重要です。
+"public" データも、"protected" データも、どちらも、
+そのようなものは心の中からなくしましょう。
+それらは、魅惑的ですが、詰まるところ、有害な考えです。
+両方とも、戻って来て、あなたに噛みつくでしょう。
+全ての状態が完全にプライベートだと考えられ、それ自身のアクセサメソッドの
+観点から保存される、
+安定した位置から外れるとすぐに、そのエンベロープを破ることになるからです。
+カプセル化されているエンベロープに穴を開けていると、
+未来の実装の変更が関係ないコードを壊す時、誰かが代価を払うことは、間違いない。
+この不完全な結果を避ける考えは、まさに、最初の場所でオブジェクトの
+オリエンテーションを始めることで、卑屈な抽象化のスリングと弓の被害を被るのに
+同意する理由です。
+そのような破損は極端に不運のようです(訳註:よくわからない)。
+
+=head2 More Inheritance Concerns
+
+(より多くの継承の懸念)
+
+=begin original
+
+Suppose that Some_Class were used as a base class from which to derive
+Another_Class. If you invoke a &CData method on the derived class or
+on an object of that class, what do you get? Would the derived class
+have its own state, or would it piggyback on its base class's versions
+of the class attributes?
+
+=end original
+
+Some_Class が、派生の Another_Class から基底クラスとして
+使われているとしましょう。
+&CData メソッドを、派生クラスか、派生クラスのオブジェクトで呼んだら、
+何を得るでしょうか？
+派生クラスは、その自身の状態があるのか、それとも、
+基底クラスのクラス属性の変数におんぶするのでしょうか？
+
+=begin original
+
+The answer is that under the scheme outlined above, the derived class
+would B<not> have its own state data. As before, whether you consider
+this a good thing or a bad one depends on the semantics of the classes
+involved.
+
+=end original
+
+その答えは上で要点をまとめた枠組のもとにあります。
+派生クラスはそれ自身の状態データがあり B<ません>。
+前のように、これを良いことと思うか、悪いことと思うか、
+関係するクラスの意味によります。
+
+=begin original
+
+The cleanest, sanest, simplest way to address per-class state in a
+lexical is for the derived class to override its base class's version
+of the method that accesses the class attributes. Since the actual method
+called is the one in the object's derived class if this exists, you
+automatically get per-class state this way. Any urge to provide an
+unadvertised method to sneak out a reference to the %ClassData hash
+should be strenuously resisted.
+
+=end original
+
+レキシカルで、クラスごとの状態を扱う、最も綺麗な、最も健全で、最も単純な
+方法は、クラス属性にアクセスするメソッドの基底クラスのバージョンを
+派生クラス用に、オーバーライドすることです。
+呼び出される実際のメソッドが、オブジェクトの派生クラスのものなので、
+もしあれば、この方法で、クラス後との状態を時動的に得ます。
+%ClassData ハッシュへのリファレンスをこっそり外に持ち出すめの、
+非公式のメソッドを提供する衝動に、はげしく耐えるべきです。
+
+=begin original
+
+As with any other overridden method, the implementation in the
+derived class always has the option of invoking its base class's
+version of the method in addition to its own. Here's an example:
+
+=end original
+
+他のオーバーライドされたメソッドと同様に、派生クラスの実装にはいつも、
+自分自身のバージョンとは別に、その基底クラスバージョンのメソッドを
+呼び出すオプションがあります。
+その例です:
+
+ package Another_Class;
+ @ISA = qw(Some_Class);
+
+ my %ClassData = (
+ CData1 => "",
+ );
+
+ sub CData1 {
+ my($self, $newvalue) = @_;
+ if (@_ > 1) {
+ # set locally first
+ $ClassData{CData1} = $newvalue;
+
+ # then pass the buck up to the first
+ # overridden version, if there is one
+ if ($self->can("SUPER::CData1")) {
+ $self->SUPER::CData1($newvalue);
+ }
+ }
+ return $ClassData{CData1};
+ }
+
+=begin original
+
+Those dabbling in multiple inheritance might be concerned
+about there being more than one override.
+
+=end original
+
+オーバーライドよりも、多重継承に首をつっこむとが、考えられます。
+
+ for my $parent (@ISA) {
+ my $methname = $parent . "::CData1";
+ if ($self->can($methname)) {
+ $self->$methname($newvalue);
+ }
+ }
+
+=begin original
+
+Because the &UNIVERSAL::can method returns a reference
+to the function directly, you can use this directly
+for a significant performance improvement:
+
+=end original
+
+&UNIVERSAL::can メソッドは、関数へのリファレンスを、直接に返します。
+ですので、重要なパフォーマンスの改良のために、これを直接に使うことが
+できます。
+
+ for my $parent (@ISA) {
+ if (my $coderef = $self->can($parent . "::CData1")) {
+ $self->$coderef($newvalue);
+ }
+ }
+
+=begin original
+
+If you override C<UNIVERSAL::can> in your own classes, be sure to return the
+reference appropriately.
+
+=end original
+
+If you override C<UNIVERSAL::can> in your own classes, be sure to return the
+reference appropriately.
+(TBT)
+
+=head2 Locking the Door and Throwing Away the Key
+
+(ドアに施錠して、鍵を放り投げる)
+
+=begin original
+
+As currently implemented, any code within the same scope as the
+file-scoped lexical %ClassData can alter that hash directly. Is that
+ok? Is it acceptable or even desirable to allow other parts of the
+implementation of this class to access class attributes directly?
+
+=end original
+
+現在インプリメントされるように、ファイルスコープのレキシカル変数の
+%ClassData と同じ範囲内のどのコードでも、そのハッシュを直接に、変更できます。
+これは良いでしょうか？
+このクラスの実装の他の部分が、直接にクラス属性にアクセスすることを許すことは、
+受け入れられか、望ましいものでしょうか？
+
+=begin original
+
+That depends on how careful you want to be. Think back to the Cosmos
+class. If the &supernova method had directly altered $Cosmos::Stars or
+C<$Cosmos::Cosmos{stars}>, then we wouldn't have been able to reuse the
+class when it came to inventing a Multiverse. So letting even the class
+itself access its own class attributes without the mediating intervention of
+properly designed accessor methods is probably not a good idea after all.
+
+=end original
+
+このことは、あなたがどれくらい注意深くありたいかに依存します。
+Cosmoクラスに戻って、考えてください。
+&supernova メソッドが直接に、$Cosmos::Starts か、
+C<$colsmos::Cosmos{stars}> を変更していたら、Multiverse を考案するときに、
+クラスを再利用することができなかったでしょう。
+クラスそれ自身でさえも、そのクラス属性に、適切に設計されたアクセサメソッドが
+仲介している介入なしに、アクセスするのは、結局、良い考えではないでしょう。
+
+=begin original
+
+Restricting access to class attributes from the class itself is usually
+not enforceable even in strongly object-oriented languages. But in Perl,
+you can.
+
+=end original
+
+クラス自身からクラス属性へのアクセスを制限するのは、ふつう、
+強力なオブジェクト指向言語でさえ、強制されていません。
+ですが、Perl では、できます。
+
+=begin original
+
+Here's one way:
+
+=end original
+
+一つの方法です:
+
+ package Some_Class;
+
+ { # scope for hiding $CData1
+ my $CData1;
+ sub CData1 {
+ shift; # XXX: unused
+ $CData1 = shift if @_;
+ return $CData1;
+ }
+ }
+
+ { # scope for hiding $CData2
+ my $CData2;
+ sub CData2 {
+ shift; # XXX: unused
+ $CData2 = shift if @_;
+ return $CData2;
+ }
+ }
+
+=begin original
+
+No one--absolutely no one--is allowed to read or write the class
+attributes without the mediation of the managing accessor method, since
+only that method has access to the lexical variable it's managing.
+This use of mediated access to class attributes is a form of privacy far
+stronger than most OO languages provide.
+
+=end original
+
+誰も-- 絶対に誰も -- クラス属性に、支配しているアクセサメソッドの
+仲介なしには、クラス属性を読み書きすることを許されていません。
+メソッドだけが、支配ているレキシカル変数にアクセスするからです。
+この、クラス属性への仲介するアクセスの使用は、ほとんどの、オブジェクト指向
+言語が提供するものよりも、はるかに強力な、プライバシーの形です。
+
+=begin original
+
+The repetition of code used to create per-datum accessor methods chafes
+at our Laziness, so we'll again use closures to create similar
+methods.
+
+=end original
+
+データごとの アクセサメソッドを作成するために使用される、コードを
+反復するのは、不精を苛立だせます。
+ですので、似たようなメソッドを作成するのに、再びクロージャを使用しましょう。
+
+ package Some_Class;
+
+ { # scope for ultra-private meta-object for class attributes
+ my %ClassData = (
+ CData1 => "",
+ CData2 => "",
+ );
+
+ for my $datum (keys %ClassData ) {
+ no strict "refs";
+ *$datum = sub {
+ use strict "refs";
+ my ($self, $newvalue) = @_;
+ $ClassData{$datum} = $newvalue if @_ > 1;
+ return $ClassData{$datum};
+ }
+ }
+
+ }
+
+=begin original
+
+The closure above can be modified to take inheritance into account using
+the &UNIVERSAL::can method and SUPER as shown previously.
+
+=end original
+
+上のクロージャは、以前に示した、&UNIVERSAL::can メソッドと SUPER を使用して、
+継承を考慮に入れるために修正できます。
+
+=head2 Translucency Revisited
+
+(半透明、再び)
+
+=begin original
+
+The Vermin class demonstrates translucency using a package variable,
+eponymously named %Vermin, as its meta-object. If you prefer to
+use absolutely no package variables beyond those necessary to appease
+inheritance or possibly the Exporter, this strategy is closed to you.
+That's too bad, because translucent attributes are an appealing
+technique, so it would be valuable to devise an implementation using
+only lexicals.
+
+=end original
+
+Veriman クラスは、そのメタオブジェクトとして、パッケージ変数、
+クラスの名前の %Vermin を使って、半透明性をデモンストレーションしました。
+継承か、もしかすると、Exporter を和らげるそれらの必需品以上に、
+絶対に、パッケージでない変数を使いたいなら、この作戦は、身近なものです。
+残念なことに、半透明の属性はアピールするテクニックですので、
+レキシカル変数のみを使う実装を考え出す価値のあるものです。
+
+=begin original
+
+There's a second reason why you might wish to avoid the eponymous
+package hash. If you use class names with double-colons in them, you
+would end up poking around somewhere you might not have meant to poke.
+
+=end original
+
+2 つ目のクラスの名前のハッシュを避けたいと思う理由があります。
+それらに、ダブルコロンのクラス名を使うと、
+つつくつもりのないどこかを、結局、つつくことになるでしょう。
+
+ package Vermin;
+ $class = "Vermin";
+ $class->{PopCount}++;
+ # accesses $Vermin::Vermin{PopCount}
+
+ package Vermin::Noxious;
+ $class = "Vermin::Noxious";
+ $class->{PopCount}++;
+ # accesses $Vermin::Noxious{PopCount}
+
+=begin original
+
+In the first case, because the class name had no double-colons, we got
+the hash in the current package. But in the second case, instead of
+getting some hash in the current package, we got the hash %Noxious in
+the Vermin package. (The noxious vermin just invaded another package and
+sprayed their data around it. :-) Perl doesn't support relative packages
+in its naming conventions, so any double-colons trigger a fully-qualified
+lookup instead of just looking in the current package.
+
+=end original
+
+最初のケースでは、クラスの名前にはダブルコロンがなかったので、現在の
+パッケージのハッシュを得ました。
+ですが、次のケースでは、現在のパッケージのハッシュを得る代わりに、
+Vermin パッケージの、ハッシュ %Noxious を得ました。
+(有害な社会の害虫は、他のパッケージに侵入し、そのまわりに、自分のデータを
+広げます :-) Perlは、その名前の慣例に、関連のあるパッケージを
+サポートしません。
+ですので、ダブルコロンは、現在のパッケージの中を見るだけではなく、
+完全修飾されたルックアップを引き起こします。
+
+=begin original
+
+In practice, it is unlikely that the Vermin class had an existing
+package variable named %Noxious that you just blew away. If you're
+still mistrustful, you could always stake out your own territory
+where you know the rules, such as using Eponymous::Vermin::Noxious or
+Hieronymus::Vermin::Boschious or Leave_Me_Alone::Vermin::Noxious as class
+names instead. Sure, it's in theory possible that someone else has
+a class named Eponymous::Vermin with its own %Noxious hash, but this
+kind of thing is always true. There's no arbiter of package names.
+It's always the case that globals like @Cwd::ISA would collide if more
+than one class uses the same Cwd package.
+
+=end original
+
+実際問題、Vermin クラスには、吹き飛ばした、%Noxious という名前の、
+存在するパッケージ変数は、ありそうもないです。
+まだ、信用できないなら、ルールを知っている自分の領域を、つねに
+見張ることができます。
+Eponymous::Vermin::Noxious か、Hieronymus::Vermin::Boschious か、
+Leave_Me_Alone::Vermin::Noxious を、クラス名として、代わりに、使うように。
+確かに、 他の誰かが、Eponymous::Vermin という名のクラスを、
+それ自身の %Noxious ハッシュと一緒に持つことは、理論上は可能ですが、
+この種類のことは、つねに真実です。
+パッケージの名前の得決定者はいません。
+2 つ以上のクラスが同じ Cwd パッケージを使うなら、@Cwd::ISA のようなグローバル
+変数が衝突するするのは、ありがちなケースです。
+
+=begin original
+
+If this still leaves you with an uncomfortable twinge of paranoia,
+we have another solution for you. There's nothing that says that you
+have to have a package variable to hold a class meta-object, either for
+monadic classes or for translucent attributes. Just code up the methods
+so that they access a lexical instead.
+
+=end original
+
+パラノイアの不快な苦痛がまだ残っているなら、別の解決法があります。
+一価のクラスのために、あるいは半透明の属性のために、
+クラスのメタオブジェクトにを持つのに、パッケージ変数を
+持たなくてはいけないとするものは何もありません。
+代わりに、レキシカルにアクセスするようなメソッドをコードにしてください。
+
+=begin original
+
+Here's another implementation of the Vermin class with semantics identical
+to those given previously, but this time using no package variables.
+
+=end original
+
+Vermin クラスの別の実装です。
+以前に与えられたものと同じ意味ですが、今回は、パッケージ変数を
+使っていません。
+
+ package Vermin;
+
+
+ # Here's the class meta-object, eponymously named.
+ # It holds all class data, and also all instance data
+ # so the latter can be used for both initialization
+ # and translucency. it's a template.
+ my %ClassData = (
+ PopCount => 0, # capital for class attributes
+ color => "beige", # small for instance attributes
+ );
+
+ # constructor method
+ # invoked as class method or object method
+ sub spawn {
+ my $obclass = shift;
+ my $class = ref($obclass) || $obclass;
+ my $self = {};
+ bless($self, $class);
+ $ClassData{PopCount}++;
+ # init fields from invoking object, or omit if
+ # invoking object is the class to provide translucency
+ %$self = %$obclass if ref $obclass;
+ return $self;
+ }
+
+ # translucent accessor for "color" attribute
+ # invoked as class method or object method
+ sub color {
+ my $self = shift;
+
+ # handle class invocation
+ unless (ref $self) {
+ $ClassData{color} = shift if @_;
+ return $ClassData{color}
+ }
+
+ # handle object invocation
+ $self->{color} = shift if @_;
+ if (defined $self->{color}) { # not exists!
+ return $self->{color};
+ } else {
+ return $ClassData{color};
+ }
+ }
+
+ # class attribute accessor for "PopCount" attribute
+ # invoked as class method or object method
+ sub population {
+ return $ClassData{PopCount};
+ }
+
+ # instance destructor; invoked only as object method
+ sub DESTROY {
+ $ClassData{PopCount}--;
+ }
+
+ # detect whether an object attribute is translucent
+ # (typically?) invoked only as object method
+ sub is_translucent {
+ my($self, $attr) = @_;
+ $self = \%ClassData if !ref $self;
+ return !defined $self->{$attr};
+ }
+
+ # test for presence of attribute in class
+ # invoked as class method or object method
+ sub has_attribute {
+ my($self, $attr) = @_;
+ return exists $ClassData{$attr};
+ }
+
+=head1 NOTES
+
+(注意)
+
+=begin original
+
+Inheritance is a powerful but subtle device, best used only after careful
+forethought and design. Aggregation instead of inheritance is often a
+better approach.
+
+=end original
+
+継承は強力ですが、繊細な仕組みです。
+注意深い見通しと設計の後で使うのが一番です。
+継承の代わりに、集約が、よりよいアプローチであることがよくあります。
+
+=begin original
+
+You can't use file-scoped lexicals in conjunction with the SelfLoader
+or the AutoLoader, because they alter the lexical scope in which the
+module's methods wind up getting compiled.
+
+=end original
+
+SelfLoader か、AutoLoader との接続では、ファイルスコープのレキシカル変数を
+使えません。
+モジュールのメソッドが、結局コンパイルされるレキシカルスコープを
+変更するからです。
+
+=begin original
+
+The usual mealy-mouthed package-munging doubtless applies to setting
+up names of object attributes. For example, C<< $self->{ObData1} >>
+should probably be C<< $self->{ __PACKAGE__ . "_ObData1" } >>, but that
+would just confuse the examples.
+
+=end original
+
+ふつう当り障りのない、パッケージのマンジングは、確かに、オブジェクト属性の
+名前をセットするのに、適合します。
+たとえば、C<< $self->{ObData1} >> は、おそらく、
+C<< $self->{ __PACKAGE__ . "_ObData1" } >> であるべきです。
+ですが、それは、例を混乱させるだけだったでしょう、
+
+=head1 SEE ALSO
+
+=begin original
+
+L<perltoot>, L<perlobj>, L<perlmod>, and L<perlbot>.
+
+=end original
+
+L<perltoot>, L<perlobj>, L<perlmod>, L<perlbot>。
+
+=begin original
+
+The Tie::SecureHash and Class::Data::Inheritable modules from CPAN are
+worth checking out.
+
+=end original
+
+CPAN にある Tie::SecureHash と、Class::Data::Inheritable モジュールは、
+良く調べる価値があります。
+
+=head1 AUTHOR AND COPYRIGHT
+
+(著者と著作権)
+
+Copyright (c) 1999 Tom Christiansen.
+All rights reserved.
+
+This documentation is free; you can redistribute it and/or modify it
+under the same terms as Perl itself.
+
+Irrespective of its distribution, all code examples in this file
+are hereby placed into the public domain. You are permitted and
+encouraged to use this code in your own programs for fun
+or for profit as you see fit. A simple comment in the code giving
+credit would be courteous but is not required.
+
+=head1 ACKNOWLEDGEMENTS
+
+(謝辞)
+
+Russ Allbery, Jon Orwant, Randy Ray, Larry Rosler, Nat Torkington,
+and Stephen Warren all contributed suggestions and corrections to this
+piece. Thanks especially to Damian Conway for his ideas and feedback,
+and without whose indirect prodding I might never have taken the time
+to show others how much Perl has to offer in the way of objects once
+you start thinking outside the tiny little box that today's "popular"
+object-oriented languages enforce.
+
+=head1 HISTORY
+
+(履歴)
+
+Last edit: Sun Feb 4 20:50:28 EST 2001
+