試訳「Mooseの未来」 ~ Moose開発ブログより

| コメント(0)

Here is a Japanese translation of the entry "The Future of Moose" on "Call of the Moose" which blogged by the Moose development team. The original text and the translation are licensed under a Creative Commons License.

Moose開発チームがブログ「Mooseの呼び声」に書いた「Mooseの未来」という記事の日本語訳です。原文とこの翻訳はCreative Commons Licenseでライセンスされています。

I knew that Moose will be modified greatly on the post via the tweet by lestrrat. It is so attractive for me who is an end-user. In a related matter, MooseX::* extensions will march greatly on modification, and I may have an unexpected injury in a case of that I put my codes into complicated with Moose. Fortunately, Moose seems to be proposed to such a release plan as Perl itself (as will be appreciated from the notation of version number), so I want to go over my codes radically before the actual release comes out.


I apologize for the fairly irresponsible translation. Any feedback on the translation are welcome.


The Future of Moose


By Jesse Luehrs on November 17, 2010 11:36 PM

ジェシー・ルアズによる、2010年11月17日 午後11時36分の投稿


A complaint that has come up multiple times over the past few months is that, as important as Moose is becoming in the Perl ecosystem, it should be more concerned with backwards compatibility.

過去数ヶ月の間に複数回寄せられた不満というのは、次のようなものである。MooseはPerlの生態系(ecosystem)と同様に重要なものとなったので、後方互換性(backwards compatibility)へさらなる関心を持つべきである、と。

After a series of discussions, the Moose development team has come up with a support policy that seems to satisfy most people; you can read about it here.


The main points are: Moose will be moving to a time-boxed release cycle of three months between (major) releases.

その概要は、(大規模)リリース((major) releases)の間隔を3ヶ月とする、タイムボックス化された(time-boxed, 訳注:あらかじめ期限を区切っておくこと)リリースサイクルへ、Mooseが移行するというものだ。

Bug fixes and minor features can be added in between major releases as long as they don't break backwards compatibility (and we will put more effort into making sure they don't).


Major releases can break backwards compatibility, but we will release at least one (ideally more than one) trial release before the actual release comes out, so that people can test their own systems with the new features, and report back with issues they may have.

大規模リリースは後方互換性を壊しうるが、我々は最低でも1つ、理想としては1つ以上の試行版(trial release)を、正式版(actual release)を出すより先に公開するつもりだ。だから、皆さんは新機能を備えた各自のシステムをテストできるし、もしあれば問題を報告することもできる。

We will also do our best to assist maintainers of Moose extensions with updating their modules for major changes, but not to the point of taking over maintainership of extensions that have become unmaintained.


If you rely on a Moose extension whose maintainer has abandoned it, feel free to find someone willing to take up maintainership, and come talk to us on #moose, we'll be more than willing to help you get up to speed.



Now, on to the fun part(: The next Moose release will contain several exciting new improvements, both for users and extension authors.


The first is that there has been a significant effort to speed up Moose's compilation time, through several means.


The largest and most obvious is that Package::Stash, the module that Moose uses to do its symbol table manipulation (for adding and retrieving methods, among other things), has been rewritten entirely in XS.

最大かつ最も明白な成果としては、Package::Stashがある。これは、Mooseが(とりわけ、メソッドを追加および取得するために)シンボルテーブル(symbol table)を操作するために使っているものだ。これが全面的にXSで書き直されている。

Since Moose spends over a third of its compilation time doing symbol table manipulation, this seemed like a good optimization target, and this turns out to have been correct - it resulted in a 10-15% speedup across the board for Moose application compile times.


Another advantage to this is that it fixes a couple (admittedly minor) long-standing bugs in the Class::MOP::Package API, since the symbol table API available from pure perl has several inherent issues itself.


Another area that should see significant improvement is in code which uses the native delegation attribute traits.

重要な改善点とみなされるべきもう一つの分野は、ネイティブな委譲アトリビュートトレート(native delegation attribute traits)を使うコードに存在する。

Previously (ever since the rewrite in 1.15), the traits themselves were loaded lazily (i.e. Moose::Meta::Attribute::Native::Trait::Bool wasn't loaded unless you actually declared an attribute with traits => ['Bool']), but the implementations of each native delegation were all loaded at once, when the trait itself was loaded.

以前には、つまり1.15(訳注:バージョン1.15のMoose)で書き直されて以来ずっと、このトレートは自分自身を遅延ロードしていた(loaded lazily)。すなわち、traits => ['Bool']というオプションをアトリビュートへ明確に記述しない限り、Moose::Meta::Attribute::Native::Trait::Boolはロードされなかった。しかしこのネイティブ委譲のそれぞれの実装は、トレートがロードされた時点で、一度に全てがロードされるというものであった。

This has been fixed, and should be another fairly large speedup for applications which use only a couple native delegations from the traits they use (which is the case the vast majority of the time).


Finally, the way method metaobjects are cached has been improved, which speeds up the introspection of methods (which happens frequently during compilation) a small but noticeable amount.

最後に、メソッドメタオブジェクト(method metaobjects, 訳注:「メソッド」オブジェクト)のキャッシュ方法が改善された。それは(コンパイルの間に頻繁に発生する)イントロスペクション(introspection, 訳注:オブジェクトの中身を実行時に参照すること)を、小さいが顕著な量ごとに高速化したということだ。

Here are some links to some relevant profiling data (run on my netbook under full profiling, which is why the times are so high): "perl -MKiokuDB -e1" with Moose 1.19: 8.60s, "perl -MKiokuDB -e1" with Moose git: 6.38s, "perl -MMarkdent::Simple::Document -e1" with Moose 1.19: 13.9s, "perl -MMarkdent::Simple::Document -e1" with Moose git: 10.6s.

それではここで、関連するプロファイリングのデータを示すリンクのいくつかをお見せしよう。これらは全て私のネットブックでプロファイリングしたものだから、やや高めの値が出ている。まず、"perl -MKiokuDB -e1" をMoose 1.19で動かすと8.60秒かかるのに対して、"perl -MKiokuDB -e1"をgit(訳注:のリポジトリ上にある開発中)のMooseで動かすと6.38秒かかる。また、"perl -MMarkdent::Simple::Document -e1"をMoose 1.19で動かすと13.9秒かかるのに対して、"perl -MMarkdent::Simple::Document -e1"をgitのMooseで動かすと10.6秒かかる。

These changes should have minimal compatibility impact (and none at all if you don't use the Class::MOP::Package API); a more detailed discussion is in Moose::Manual::Delta.



In terms of features, we have made a fairly significant change to how attribute metaroles work.

機能については、アトリビュートメタロール(attribute metaroles, 訳注:「アトリビュート」ロール)の働きについて、我々はかなり重大な変更を加えている。

Previously, when a role was applied to a class, it would copy the attributes from the role into the class using the class's default attribute metaclass, prior to applying the traits specified in the attribute definition.

以前のそれは、つまりロールがクラスに適用されていた時のそれは、アトリビュートの定義部で指定されたトレートが適用されるより前に、クラスのデフォルトのアトリビュートメタクラス(attribute metaclass, 訳注:「アトリビュート」クラス)を使っているクラスへと、アトリビュートをロールからコピーするという挙動であった。

This is obviously incorrect with a bit of thought - attribute metaclasses completely define how the attribute works, including things like how accessors are generated.


If a role contains an attribute and some methods, those methods need to be able to know what method name the accessor is going to be installed under, or the role won't work.


A good example of this is a class which uses MooseX::FollowPBP consuming a role which doesn't - currently, this completely breaks the role.

その好例は、MooseX::FollowPBPを使うクラスが(現在は)動かないロールを消費(consuming a role, 訳注:with構文でクラスやロールにロールを取り込むこと)していることである。

With this change, roles now have their own default attribute metaclass, separate from any class.


This also allows for an additional feature - when writing extensions, you can specify the 'applied_attribute' option to the 'role' block in 'apply_metaroles' to specify a set of default traits that all attributes defined in that role will receive when they are applied to a class.


This should work identically to the 'attribute' option in the 'class' block, and should allow extensions which add default attribute metaroles (such as MooseX::Aliases) to work identically in both classes and roles (unlike currently, where the trait must be applied explicitly in role attributes).


The downside to this is that it breaks backwards compatibility in a potentially confusing way: if you were assuming and relying on role attributes using the class's attribute metaclass, your roles will break, and there isn't really a way to detect this.


The solution will be to use the same extensions in your roles that you do in the classes that consume those roles, but as noted previously, attribute metaroles don't currently work in roles.


These extensions will be fixed by the time we make an actual release.



Finally, there is also some good news for extension authors: the inlining API should be much more sane, and the code itself should be much more readable, so adding inlined method generation support to your modules which affect accessor or constructor/destructor generation should be much, much easier now.

最後に、拡張モジュールの作者への良い知らせがもう一つある。APIのインライン化(inlining API)はより健全なものになり、それらのコードはより読みやすいものになる。インライン化されたメソッドの生成は、アクセッサーやコンストラクターとデストラクターの生成に関係するあなたのモジュールについて、それらをとてもとても簡単に行えるように支援するようにもなる。

Some highlights include: the attribute metaclass and class metaclass controlling entirely how the bodies of the methods they generate are created (so there should no longer be a need to write accessor or constructor metaclass traits), accessor generation in Class::MOP and Moose going through one much simplified codepath (read: removed the obscene amount of code duplication between Class::MOP and Moose), so figuring out how a given accessor is generated should be pretty trivial now, and constructors now asking the attribute metaclass how to initialize attributes at construction time, rather than doing it themselves with a bunch of duplicated code (so in the case of simple attribute traits which affect accessor generation, manually modifying the constructor generation shouldn't even be necessary).

これにはいくつかのハイライトが含まれる。まず、アトリビュートメタクラスとクラスメタクラス(class metaclass, 訳注:「クラス」クラス)は、生成されるメソッドの本体をどのように作成するかを、完全に制御するようになる。また、Class::MOPとMooseでのアクセッサーの生成は、ただ一つの単純化されたコードパスによって行われるようになる。Class::MOPとMooseで重複していた気持ち悪いくらいの量のコードは取り除かれたのだ。従って、与えられたアクセッサーの生成方法を解明することは、もはや相当に些細な問題になる。そしてコンストラクターは、これからは、コンストラクト時にアトリビュートをどのように初期化すべきかを、複製されたコードの一群と共にコンストラクター自身が行うのではなく、アトリビュートメタクラスに対して確認するようになる。なお、アクセッサーの生成を行う単純なアトリビュートトレートの場合、コンストラクターの生成を手動で修正する必要すらなくなる。

The downside to this is, as you may have guessed, the API for doing code inlining has been changed pretty radically.


This will require some work on the part of extension authors, in order to use the new API (since there's not really a non-insane way to support both APIs), but again, we'll be working with extension authors to make sure this happens before our actual release, and we'll be releasing a few dev releases prior to the actual release to allow people with non-CPAN code to have a chance to update their code.

これは一部の拡張モジュール作者に対して、新たなAPIを使うための、いくらかの作業を要求するものだ。それは(新旧)両方のAPIをサポートするための、それほど突飛ではない方法が存在するようになってからだ。しかし思い起こしてもらいたいのは、それらが問題なく動作することを確認するために、我々の正式版のリリースよりも前に、我々が拡張モジュールの作者たちと共に作業するであろうということだ。そして我々は、CPANモジュールでないコードを使っている皆さんが、自身のコードを更新するための機会を確保できるよう、いくつかの開発版(dev releases)を正式版よりも前にリリースするだろう。


As far as a plan goes, we're looking to have our first trial release out by the end of this month, and are aiming for the actual release to happen sometime in late December or early January.


If you have any questions about the new release and support process, or about any of these new features, definitely let us know - we're very open to feedback, either here, on the Moose mailing list, or on #moose-dev on IRC.




  • Twitter: @gardejo
  • GitHub: gardejo
  • CodeRepos: gardejo


Eorzea System Worksは、架空のシステム開発結社です。

FF14.name (FinalFantasyXIV.name)では、アヴァター(プレイヤーキャラクター)の管理システムやイベント出欠・リマインダシステムや、リンクシェル(LS)運営・管理システムやDKPシステムなどを設計・開発・公開する予定です。



リンク, トラックバック歓迎





このページは、Gardejoが2010年11月30日 23:48に書いたブログ記事です。


次のブログ記事は「DBIx::ObjectMapper、または私は如何にして心配するのを止めてData Mapperパターンを愛するようになったか」です。



2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28