mro-1.00 > mro
mro-1.00
Other versions:
mro-1.01

名前

mro - Method Resolution Order

mro - メソッド解決順序(Method Resolution Order)

概要

  use mro; # enables next::method and friends globally

  use mro 'dfs'; # enable DFS MRO for this class (Perl default)
  use mro 'c3'; # enable C3 MRO for this class

説明

The "mro" namespace provides several utilities for dealing with method resolution order and method caching in general.

"mro" 名前空間はメソッド解決順序と一般的なメソッドキャッシュを扱うための いくつかのユーティリティを提供します。

These interfaces are only available in Perl 5.9.5 and higher. See MRO::Compat on CPAN for a mostly forwards compatible implementation for older Perls.

これらのインターフェースは Perl 5.9.5 以上でのみ利用可能です。 より古い Perl のための、ほとんど前方互換な実装については CPAN の MRO::Compat を参照してください。

概観

It's possible to change the MRO of a given class either by using use mro as shown in the synopsis, or by using the "mro::set_mro" function below. The functions in the mro namespace do not require loading the mro module, as they are actually provided by the core perl interpreter.

あるクラスの MRO は、上述の use mro を使うか、以下の "mro::set_mro" 関数を使うことで変更できます。 mro 名前空間の関数は mro モジュールを読み込む必要はなく、実際には コア perl インタプリタによって提供されます。

The special methods next::method, next::can, and maybe::next::method are not available until this mro module has been loaded via use or require.

特殊メソッド next::method, next::can, maybe::next::methoduserequire によって mro モジュールを読み込むまで 利用できません。

The C3 MRO

In addition to the traditional Perl default MRO (depth first search, called DFS here), Perl now offers the C3 MRO as well. Perl's support for C3 is based on the work done in Stevan Little's module Class::C3, and most of the C3-related documentation here is ripped directly from there.

伝統的な Perl のデフォルトの MRO (深さ優先探索 (depth first search); ここでは DFS と呼ばれます)に加えて、Perl は C3 MRO も 提供するようになりました。 Perl の C3 対応は Stevan Little による Class::C3 モジュールで行われた 作業を基としていて、ここにある C3 関係の文章のほとんどは、そこから直接 コピーされたものです。

C3 って何?

C3 is the name of an algorithm which aims to provide a sane method resolution order under multiple inheritance. It was first introduced in the language Dylan (see links in the "SEE ALSO" section), and then later adopted as the preferred MRO (Method Resolution Order) for the new-style classes in Python 2.3. Most recently it has been adopted as the "canonical" MRO for Perl 6 classes, and the default MRO for Parrot objects as well.

C3 は多重継承における健全なメソッド解決順序を提供することを目的とした アルゴリズムの名前です。 これは最初に Dylan と言う言語 ("SEE ALSO" の章のリンクを 参照してください)、で導入され、後に Python 2.3 の新型のクラスでの 優先 MRO (Method Resolution Order; メソッド解決順序) として採用されました。 つい最近では Perl 6 のクラスでの「正統な」MRO として採用され、Parrot プロジェクトでもデフォルトの MRO として採用されました。

C3 の動作

C3 works by always preserving local precendence ordering. This essentially means that no class will appear before any of its subclasses. Take, for instance, the classic diamond inheritance pattern:

C3 は常に局所的な優先順位を保存して動作します。 これは、基本的にどのクラスもそのサブクラスより先に現れることはないことを 意味します。 例えば、以下のような古典的なダイヤ型継承パターンを考えます:

     <A>
    /   \
  <B>   <C>
    \   /
     <D>

The standard Perl 5 MRO would be (D, B, A, C). The result being that A appears before C, even though C is the subclass of A. The C3 MRO algorithm however, produces the following order: (D, B, C, A), which does not have this issue.

標準の Perl 5 MRO は (D, B, A, C) です。 この結果、CA のサブクラスにも関わらず、AC より先に 検索されます。 しかし、C3 MRO アルゴリズムでは、(D, B, C, A) の順序になり、この問題は ありません。

This example is fairly trivial; for more complex cases and a deeper explanation, see the links in the "SEE ALSO" section.

この例はかなりつまらないものです; より複雑な場合とより深い説明については、 "SEE ALSO" の章のリンクを参照してください。

関数

mro::get_linear_isa($classname[, $type])

Returns an arrayref which is the linearized MRO of the given class. Uses whichever MRO is currently in effect for that class by default, or the given MRO (either c3 or dfs if specified as $type).

与えられたクラスの、線形化された MRO を含む配列リファレンスを返します。 このクラスで有効な MRO はデフォルトか、あるいは与えられた MRO ($type として指定されていれば c3dfs のどちらか) かを使います。

The linearized MRO of a class is an ordered array of all of the classes one would search when resolving a method on that class, starting with the class itself.

あるクラスの、線形化された MRO とは、そのクラスでメソッドを解決するときに 検索する(自分自身のクラスを先頭とする)全てのクラスの順序付き配列です。

If the requested class doesn't yet exist, this function will still succeed, and return [ $classname ]

要求されたクラスがまだ存在していない場合、この関数はそれでも成功し、 [ $classname ] を返します。

Note that UNIVERSAL (and any members of UNIVERSAL's MRO) are not part of the MRO of a class, even though all classes implicitly inherit methods from UNIVERSAL and its parents.

UNIVERSAL (および UNIVERSAL の MRO のメンバ) は、あるクラスの MRO の一部ではないことに注意してください; 全てのクラスは暗黙に UNIVERSAL とその親を継承しているにも関わらず、です。

mro::set_mro($classname, $type)

Sets the MRO of the given class to the $type argument (either c3 or dfs).

与えられたクラスの MRO を $type 引数 (c3dfs のどちらか) に 設定します。

mro::get_mro($classname)

Returns the MRO of the given class (either c3 or dfs).

与えられたクラスの MRO (c3dfs のどちらか) を返します。

mro::get_isarev($classname)

Gets the mro_isarev for this class, returned as an arrayref of class names. These are every class that "isa" the given class name, even if the isa relationship is indirect. This is used internally by the MRO code to keep track of method/MRO cache invalidations.

このクラスの mro_isarev を取得して、クラス名の配列リファレンスとして 返します。 これは、例え isa 関係が間接的であっても、与えられたクラス名に対して "isa" 関係にある全てのクラスです。 これは、メソッド/MRO キャッシュの無効化を記録するために MRO コードによって 内部的に使われます。

Currently, this list only grows, it never shrinks. This was a performance consideration (properly tracking and deleting isarev entries when someone removes an entry from an @ISA is costly, and it doesn't happen often anyways). The fact that a class which no longer truly "isa" this class at runtime remains on the list should be considered a quirky implementation detail which is subject to future change. It shouldn't be an issue as long as you're looking at this list for the same reasons the core code does: as a performance optimization over having to search every class in existence.

現在のところ、このリストは伸びるだけで、縮むことはありません。 これは性能を考慮したものです (誰かが @ISA からエントリを削除したときに 適切に追跡して isarev エントリを削除するのは重い処理で、どちらにしろ しょっちゅう起きることではありません)。 実行時にはもはや本当にはこのクラスの "isa" ではないクラスがリストに 残っているということは、将来変更される予定の奇妙な実装詳細であると 考えられています。 このリストを、コアコードと同じ理由(つまり存在する全てのクラスを 検索することに対しての性能の最適化)で見ている限りは 問題にならないはずです。

As with mro::get_mro above, UNIVERSAL is special. UNIVERSAL (and parents') isarev lists do not include every class in existence, even though all classes are effectively descendants for method inheritance purposes.

上述の mro::get_mro と同様、UNIVERSAL は特殊です。 UNIVERSAL (と親) の isarev リストは存在する全てのクラスを 含んでいるわけではありません; メソッド継承の目的において 全てのクラスが事実上子孫であるにも関わらず、です。

mro::is_universal($classname)

Returns a boolean status indicating whether or not the given classname is either UNIVERSAL itself, or one of UNIVERSAL's parents by @ISA inheritance.

与えられたクラス名が、UNIVERSAL 自身あるいは @ISA 継承による UNIVERSAL の親の一つかどうかを示す真偽値を返します。

Any class for which this function returns true is "universal" in the sense that all classes potentially inherit methods from it.

この関数が真を返すあらゆるクラスは、全てのクラスが潜在的にここから メソッドを継承しているという意味で "universal" です。

For similar reasons to isarev above, this flag is permanent. Once it is set, it does not go away, even if the class in question really isn't universal anymore.

上述の isarev と同様の理由で、このフラグは恒久的です。 一旦これがセットされると、例え問い合わされたクラスが実際には もはや univeral ではないとしても、セットされたままです。

mro::invalidate_all_method_caches()

Increments PL_sub_generation, which invalidates method caching in all packages.

PL_sub_generation をインクリメントして、全てのパッケージの メソッドキャッシュを無効にします。

mro::method_changed_in($classname)

Invalidates the method cache of any classes dependent on the given class. This is not normally necessary. The only known case where pure perl code can confuse the method cache is when you manually install a new constant subroutine by using a readonly scalar value, like the internals of constant do. If you find another case, please report it so we can either fix it or document the exception here.

与えられたクラスに依存している全てのクラスのメソッドキャッシュを 無効にします。 通常これは不要です。 ピュア perl コードがメソッドキャッシュについて混乱すると知られている 唯一の場合は、constant の内部で行っているように、読み込み専用の スカラ値を使って新しい定数サブルーチンを手動で設定した場合です。 もしその他の場合を発見した場合は、どうか報告してください; それを修正するか、ここに例外として記述します。

mro::get_pkg_gen($classname)

Returns an integer which is incremented every time a real local method in the package $classname changes, or the local @ISA of $classname is modified.

パッケージ $classname の実ローカルメソッドが変更されるか、 $classname のローカルの @ISA が変更される度にインクリメントされる 整数を返します。

This is intended for authors of modules which do lots of class introspection, as it allows them to very quickly check if anything important about the local properties of a given class have changed since the last time they looked. It does not increment on method/@ISA changes in superclasses.

これは多くのクラスを調査するモジュールの作者のためを意図したもので、 与えられたクラスに対して最後に調べてからローカルな属性についての 何か重要なことが変更されたかどうかを素早く調べられるようにします。 これはスーパークラスでのメソッド/@ISA の変更では インクリメントされません。

It's still up to you to seek out the actual changes, and there might not actually be any. Perhaps all of the changes since you last checked cancelled each other out and left the package in the state it was in before.

実際の変更を探し求めるのは自由ですが、実際には何もないかもしれません。 おそらく最後にチェックしてからの全ての変更はお互いにキャンセルされ、 以前の状態のパッケージのままなのでしょう。

This integer normally starts off at a value of 1 when a package stash is instantiated. Calling it on packages whose stashes do not exist at all will return 0. If a package stash is completely deleted (not a normal occurence, but it can happen if someone does something like undef %PkgName::), the number will be reset to either 0 or 1, depending on how completely package was wiped out.

この整数は、通常パッケージスタッシュが実体化されたときに 1 から 開始します。 スタッシュが全く存在しないパッケージに対して呼び出すと、0 を返します。 パッケージスタッシュが完全に削除された場合 (通常は起きませんが、誰かが undef %PkgName:: のようなことをしたときに起こります)、数値は 01 にリセットされます (どちらになるかはどのようにしてパッケージが 完全に削除されたかに依ります)。

next::method

This is somewhat like SUPER, but it uses the C3 method resolution order to get better consistency in multiple inheritance situations. Note that while inheritance in general follows whichever MRO is in effect for the given class, next::method only uses the C3 MRO.

これはいくらか SUPER と似ていますが、多重継承の場合によりよい 一貫性を保つために C3 メソッド解決順序を使います。 一般的な継承はそのクラスに対してどの MRO が有効かに従うのに対して、 next::method は C3 MRO だけを使うことに注意してください。

One generally uses it like so:

一つの一般的な使用法は以下のようなものです:

  sub some_method {
    my $self = shift;
    my $superclass_answer = $self->next::method(@_);
    return $superclass_answer + 1;
  }

Note that you don't (re-)specify the method name. It forces you to always use the same method name as the method you started in.

メソッド名を(再)指定しないことに注意してください。 常に開始したメソッドと同じメソッド名を使うことを強制されます。

It can be called on an object or a class, of course.

これはもちろんオブジェクトやクラスを呼び出せます。

The way it resolves which actual method to call is:

呼び出す実際のメソッドを解決する方法は:

  1. First, it determines the linearized C3 MRO of the object or class it is being called on.

    まず、呼び出されたオブジェクトやクラスの線形化された C3 MRO を決定します。

  2. Then, it determines the class and method name of the context it was invoked from.

    次に、起動されたコンテキストのクラスとメソッド名を決定します。

  3. Finally, it searches down the C3 MRO list until it reaches the contextually enclosing class, then searches further down the MRO list for the next method with the same name as the contextually enclosing method.

    最後に、文脈的に囲まれているクラスに到達するまで C3 MRO リストを検索して、 文脈的に囲まれているメソッドと同じ名前の次のメソッドのために MRO リストを検索します。

Failure to find a next method will result in an exception being thrown (see below for alternatives).

次のメソッドを検索するのに失敗すると、例外が投げられます (代替案については以下を参照してください)。

This is substantially different than the behavior of SUPER under complex multiple inheritance. (This becomes obvious when one realizes that the common superclasses in the C3 linearizations of a given class and one of its parents will not always be ordered the same for both.)

これは複雑な多重継承での SUPER の振る舞いとは大きく異なります。 (これは、あるクラスの C3 線形化での共通スーパークラスと、その親が いつも同じ順序になるわけではないということに気付けば明らかです。)

Caveat: Calling next::method from methods defined outside the class:

警告: クラスの外部で定義されたメソッドからの next::method の呼び出し:

There is an edge case when using next::method from within a subroutine which was created in a different module than the one it is called from. It sounds complicated, but it really isn't. Here is an example which will not work correctly:

呼び出したのと違うモジュールで作られたサブルーチン内から next::method を 使うという、一つのエッジケースがあります。 これは複雑なように聞こえますが、実際にはそうではありません。 以下は正しく動作しない例です:

  *Foo::foo = sub { (shift)->next::method(@_) };

The problem exists because the anonymous subroutine being assigned to the *Foo::foo glob will show up in the call stack as being called __ANON__ and not foo as you might expect. Since next::method uses caller to find the name of the method it was called in, it will fail in this case.

*Foo::foo グロブに代入された無名サブルーチンは、想定される foo ではなく __ANON__ から呼び出されたものとして呼び出しスタックに現れるという 問題があります。 next::method は呼び出されたメソッドの名前を見つけるために caller を 使っているので、この場合失敗します。

But fear not, there's a simple solution. The module Sub::Name will reach into the perl internals and assign a name to an anonymous subroutine for you. Simply do this:

しかし心配はいりません; 簡単な解決法があります。 Sub::Name モジュールは perl の内部に手を入れて、名前を無名サブルーチンに 代入します。 単にこうすると:

  use Sub::Name 'subname';
  *Foo::foo = subname 'Foo::foo' => sub { (shift)->next::method(@_) };

and things will Just Work.

うまく動きます。

next::can

This is similar to next::method, but just returns either a code reference or undef to indicate that no further methods of this name exist.

これは next::method と同様ですが、単にコードリファレンスを返します; この名前のメソッドがもうない場合は undef を返します。

maybe::next::method

In simple cases, it is equivalent to:

単純な場合では、これは以下と等価です:

   $self->next::method(@_) if $self->next_can;

But there are some cases where only this solution works (like goto &maybe::next::method);

しかし、(goto &maybe::next::method のように)この方法のみが動作する 場合もあります;

SEE ALSO

The original Dylan paper

http://www.webcom.com/haahr/dylan/linearization-oopsla96.html

The prototype Perl 6 Object Model uses C3

http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/

Parrot now uses C3

http://aspn.activestate.com/ASPN/Mail/Message/perl6-internals/2746631
http://use.perl.org/~autrijus/journal/25768
http://www.python.org/2.3/mro.html
http://www.python.org/2.2.2/descrintro.html#mro

C3 for TinyCLOS

http://www.call-with-current-continuation.org/eggs/c3.html

Class::C3

Class::C3

作者

Brandon L. Black, <blblack@gmail.com>

Based on Stevan Little's Class::C3