試訳「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.

Mooseに少なからぬ変更が入ることを、lestrratさんのtweetを経由して、この記事で知りました。エンドユーザーの私から見れば大変魅力的な変更です。MooseX::*拡張モジュールもこれに紐付いて変更への大行進が行われるようですし、自分のコードでMooseの込み入ったことをやっていると、思わぬ怪我をすることもあるかもしれません。幸いにして(バージョン表記法からも分かるように)Perl本体のようなリリース計画が敷かれるようなので、正式版が出るまでの間に徹底的にコードを見直すようにしたいものです。

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

訳は相当でたらめです。ごめんなさい。訳のツッコミがありましたら是非。

The Future of Moose

Mooseの未来

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

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

第1段

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.

一連の議論の後で、Moose開発チームは、たいていの人が満足するようなサポートポリシーを考え出した。それはここで読むことができる。

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.

我々はまた、Mooseの拡張モジュールのメンテナーに対して、それらのモジュールの、大規模な(Moose本体の)変更に追従するための更新を補助することについても、最善を尽くすだろう。ただし、既にメンテナンスされなくなっている拡張モジュールについては、この限りではない。

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.

メンテナーが保守を断念しているMooseの拡張モジュールをあなたが当てにしているならば、保守を引き継いでくれるような人を気軽に捜して欲しい。そしてIRCの#mooseチャネルで我々に話しかけて欲しい。我々はあなたが予備知識を得るのを十分に手助けするつもりだ。

第2段

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

さて、現在はユカイな(訳注:大変な)状態にある。Mooseの次のリリースでは、ユーザーと拡張モジュールの作者の双方にとって、刺激的かつ新しい改善点がいくつか含まれる。

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

まず、いくつかの手段によるMooseのコンパイル時間の速度向上へ、かなりの工数が費やされている。

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.

Mooseはシンボルテーブルを操作するためにコンパイル時間の3分の1以上を費やしていたので、最適化の格好の対象であったろうし、直されるべきものでもあった。結果として、Mooseアプリケーションのコンパイル時間の全般にわたって、10~15%の高速化が実現された。

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.

その他の利点として、Class::MOP::PackageのAPIについての(明らかに小規模な)いくつかの積年のバグが、これによって修正されることが挙げられる。それはシンボルテーブルAPIについての、それがピュアPerlから使えるようになって以来の、いくつかの固有の問題であった。

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.

これらの変更は互換性へわずかに影響を及ぼす。ただしClass::MOP::PackageのAPIを使っていないのであれば全く影響はない。その詳細な考察についてはMoose::Manual::Deltaを参照して欲しい。

第3段

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.

これにより、新たな機能も実現される。拡張モジュールを記述するときに、全てのアトリビュートが定義済みであるデフォルトのトレートのセットを指定するために、'apply_metaroles'の中で、'role'ブロックへ'applied_attribute'オプションを指定することができるようになるのだ。これはロールがクラスへいつ適用されるのかを受け取るために実現される。

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).

これは'class'ブロックにある'attribute'オプションと全く同様に働くし、クラスとロールを同一の挙動にするために、(MooseX::Aliasesのような)デフォルトのアトリビュートメタロールを追加するという拡張を講じることもできる。現在はそうではなく、ロールのアトリビュートではトレートを明示的に適用しなければならない。

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.

これらの(訳注:MooseX::Aliasなどの)ロールを消費するクラスの中で、いくつかの拡張モジュールをあなたのロールで使用することが、解決法となるだろう。しかし前述のように、アトリビュートメタロールは現在はロールの中では動かない。

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

我々が正式版を作る時までに、これらの(訳注:MooseX::Aliasなどの)拡張モジュールは修正されるであろう。

第4段

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.

これについての推測されるであろう欠点は、コードのインライン化を行うAPIが根本的に変更されるということだ。

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)を正式版よりも前にリリースするだろう。

第5段

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.

計画通りに行けば、我々は今月末(訳注:2010年11月末)までに最初の試行版を出せるだろう。そして、我々は正式版を12月後半または1月前半に出すことを目指している。

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.

この新しいリリースやサポート工程について質問があるか、またはこれらの新機能について何か我々に明確に知らせておきたい事柄があるのなら、我々はそのフィードバックを歓迎している。ここ(訳注:元記事への英文コメントやトラックバック)か、Mooseのメーリングリストか、IRCの#moose-devチャネルまでお寄せいただきたい。

コメントする

筆者"Gardejo"について

  • Twitter: @gardejo
  • GitHub: gardejo
  • CodeRepos: gardejo
  • CPAN: MORIYA

このサイトについて

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

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

関連サイト

関連サイトでは、他にもFF14に関連するサイトをいくつか紹介しています。

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

このブログへのリンク(どのページでも構いません)やトラックバックを歓迎します。

設計・開発・運用の参考にさせていただきますので、コメントもお気軽にお寄せください!

個別の記事に対するご意見などのほか、目安箱もご用意しています。

このブログ記事について

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

ひとつ前のブログ記事は「人肌のPerl」です。

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

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

2014年2月

            1
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  

やや真面目なサイト