root/docs/cat-ja/Catalyst/Manual/ExtendingCatalyst.pod @ 13143

=head1 名前(NAME)

Catalyst::Manual::ExtendingCatalyst - フレームワークを拡張する

=head1 概要(DESCRIPTION)

This document will provide you with access points, techniques and best
practices to extend the L<Catalyst> framework, or to find more elegant
ways to abstract and use your own code.

このドキュメントでは Catalyst を拡張する方法やどうやってエレガントにあなたのコー
ドを抽象化するかについて論じます。

The design of Catalyst is such that the framework itself should not
get in your way. There are many entry points to alter or extend
Catalyst's behaviour, and this can be confusing. This document is
written to help you understand the possibilities, current practices
and their consequences.

Catalyst はいろんな方法で拡張できるので、あなたは混乱しているかもしれません。この
ドキュメントではそのあたりの詳細を論じます。

Please read the L<BEST PRACTICES> section before deciding on a design,
especially if you plan to release your code to CPAN. The Catalyst
developer and user communities, which B<you are part of>, will benefit
most if we all work together and coordinate.

あなたのコードを CPAN にうpするまえに、とりあえず L<BEST PRACTICES> の章をよみま
しょう。 Catalyst の開発者とユーザコミュニティはあなたとともにあります。

If you are unsure on an implementation or have an idea you would like
to have RFC'ed, it surely is a good idea to send your questions and
suggestions to the Catalyst mailing list (See L<Catalyst/SUPPORT>)
and/or come to the C<#catalyst> channel on the C<irc.perl.org>
network. You might also want to refer to those places for research to
see if a module doing what you're trying to implement already
exists. This might give you a solution to your problem or a basis for
starting.

あなたがなにか実装にまつわるアイディアをもっているのであれば、Catalyst の ML,
IRC などで話しかけてください。

=head1 ベストプラクティス(BEST PRACTICES)

During Catalyst's early days, it was common to write plugins to
provide functionality application wide. Since then, Catalyst has
become a lot more flexible and powerful. It soon became a best
practice to use some other form of abstraction or interface, to keep
the scope of its influence as close as possible to where it belongs.

Catalyst が若かりしころ、複数アプリにまたがる機能はプラグインにするのがよいとされ
えいましたが、現在ではもっとフレキシブルでパワフルな方法があります。

For those in a hurry, here's a quick checklist of some fundamental
points. If you are going to read the whole thing anyway, you can jump
forward to L</Namespaces>.

もし君がめっちゃいそいでいるのなら、以下に必須のポイントに関するクイックチェック
リストを容易したからそれだけでもよんでいきたまえ。もし君がまったりとこの文書を全
部読むつもりなら L</Namespaces> に進む。

=head2 3分間チェックリスト(Quick Checklist)

=over

=item C<CatalystX::*> というネームスペースをつかいましょう(Use the C<CatalystX::*> namespace if you can!)

If your extension isn't a Model, View, Controller, Plugin, or Engine,
it's best to leave it out of the C<Catalyst::> namespace.  Use
<CatalystX::> instead.

もしあなたの拡張が Model でも View でも Controller でも Plugin でも Engine でもな
ければ、それは C<Catalyst::> というネームスペースにおくべきではありません。
C<CatalystX::> をかわりにつかってください。

=item プラグインはつくらない(どうしてもつくらなきゃいけない場合をのぞいて)!(Don't make it a plugin unless you have to!)

A plugin should be careful since it's overriding Catalyst internals.
If your plugin doesn't really need to muck with the internals, make it a
base Controller or Model.

プラギンは Catalyst の内部をうわがきしちゃうので、注意してね!もしチミのプラグイン
が、内部を上書きしたいんでなければ、Controller か Model にしてね!

=item コミュニティがあるから利用しちゃおう!(There's a community. Use it!)

There are many experienced developers in the Catalyst community,
there's always the IRC channel and the mailing list to discuss things.

Catalyst には IRC も ML もあるから、どんどん利用しちゃおう!

=item テストとドキュメンテーションはしっかりね!(Add tests and documentation!)

This gives a stable basis for contribution, and even more importantly,
builds trust. The easiest way is a test application. See
L<Catalyst::Manual::Tutorial::Testing> for more information.

あたりまえのことだけど、テストとドキュメンテーションをしない人はお尻ペンペンだよ!

=back

=head2 ネームスペース(Namespaces)

While some core extensions (engines, plugins, etc.) have to be placed
in the C<Catalyst::*> namespace, the Catalyst core would like to ask
developers to use the C<CatalystX::*> namespace if possible.

コアの拡張(engine や plugin とか)は、C<Catalyst::*> におくべきだけど、そういうの
つくるときは開発者に相談してからにしよう。できることなら C<CatalystX::*> におこう。

(訳注: CPAN にアップロードする場合、相談してからやらないと mst に痛烈に DIS られます)

When you try to put a base class for a C<Model>, C<View> or
C<Controller> directly under your C<MyApp> directory as, for example,
C<MyApp::Controller::Foo>, you will have the problem that Catalyst
will try to load that base class as a component of your
application. The solution is simple: Use another namespace. Common
ones are C<MyApp::Base::Controller::*> or C<MyApp::ControllerBase::*>
as examples.

=head2 それをシンプルなモジュールにすることはできませんか?(Can it be a simple module?)

Sometimes you want to use functionality in your application that
doesn't require the framework at all. Remember that Catalyst is just
Perl and you always can just C<use> a module. If you have application
specific code that doesn't need the framework, there is no problem in
putting it in your C<MyApp::*> namespace. Just don't put it in
C<Model>, C<Controller> or C<View>, because that would make Catalyst
try to load them as components.

Catalyst はたんなる Perl であることを思いだしてください。C<use> でいつでもモジュー
ルをつかえるんですよ。フレームワークと連携することが必要ないアプリケーション専用
のコードであれば、C<MyApp::*> というネームスペースをつかってください。C<Model>,
C<Controller>, C<View> というネームスペースにはおかないでください。このネームスペー
スにおくと Catalyst がコンポーネントとしてロードしちゃいまっせ。

Writing a generic component that only works with Catalyst is wasteful
of your time.  Try writing a plain perl module, and then a small bit
of glue that integrates it with Catalyst.  See
L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema> for a
module that takes the approach.  The advantage here is that your
"Catalyst" DBIC schema works perfectly outside of Catalyst, making
testing (and command-line scripts) a breeze.  The actual Catalyst
Model is just a few lines of glue that makes working with the schema
convenient.

Catalyst に依存した一般的なコンポーネントをつくることは、あなたの時間を無駄に浪費
させます。素の Perl モジュールを書くことを検討してください。そして、Catalyst とは
ほんのちょっとの連携コードで連携させてください。このような方法論でつくられたモ
ジュールの代表例は Catalyst::Model::DBIC::Schema ですので参考にしてください。この
方法のよさは、DBIC のスキーマが完全に Catalyst の外でうごいているということです。
こうすることによって、テストが楽になり、コマンドラインスクリプトも簡単に書けます。
現実の Catalyst の Model は、ほんとにちょっとの連携コードで便利につかえるようにつ
なぎこまれてるのだ。

If you want the thinnest interface possible, take a look at
L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>.

もし、薄いインターフェースで連携できるんなら Catalyst::Model::Adaptor でつなぎこ
むのがよいです。

=head2 継承とメソッドのうわがき。(Inheritance and overriding methods)

While Catalyst itself is still based on L<NEXT> (for multiple
inheritance), extension developers are encouraged to use L<Class::C3>,
which is what Catalyst will be switching to in some point in the
future.

When overriding a method, keep in mind that some day additionally
arguments may be provided to the method, if the last parameter is not
a flat list. It is thus better to override a method by shifting the
invocant off of C<@_> and assign the rest of the used arguments, so
you can pass your complete arguments to the original method via C<@_>:

  use Class::C3; ...

  sub foo { my $self = shift;
            my ($bar, $baz) = @_; # ...  return
            $self->next::method(@_); }

If you would do the common

  my ($self, $foo, $bar) = @_;

you'd have to use a much uglier construct to ensure that all arguments
will be passed along and the method is future proof:

  $self->next::method(@_[ 1 .. $#_ ]);

=head2 テストとドキュメンテーション(Tests and documentation)

When you release your module to the CPAN, proper documentation and at
least a basic test suite (which means more than pod or even just
C<use_ok>, sorry) gives people a good base to contribute to the
module.  It also shows that you care for your users. If you would like
your module to become a recommended addition, these things will prove
invaluable.

CPAN にモジュールをリリースするにあたっては、きちんとしたドキュメンテーションと、
テストスィーツ(use_ok してりゃいいってもんじゃないよ)を提供してくださいな。

If you're just getting started, try using
L<CatalystX::Starter|CatalystX::Starter> to generate some example
tests for your module.

もし君が、あたらしくつくりはじめるんなら CatalystX::Starter をつかってみてくださ
いな。テストの例がはいっているよ。

=head2 メンテナンス(Maintenance)

In planning to release a module to the community (Catalyst or CPAN and
Perl), you should consider if you have the resources to keep it up to
date, including fixing bugs and accepting contributions.

If you're not sure about this, you can always ask in the proper
Catalyst or Perl channels if someone else might be interested in the
project, and would jump in as co-maintainer.

A public repository can further ease interaction with the
community. Even read only access enables people to provide you with
patches to your current development version. subversion, SVN and SVK,
are broadly preferred in the Catalyst community.

If you're developing a Catalyst extension, please consider asking the
core team for space in Catalyst's own subversion repository. You can
get in touch about this via IRC or the Catalyst developers mailing
list.

=head2 コンテキストオブジェクト(The context object)

Sometimes you want to get a hold of the context object in a component
that was created on startup time, where no context existed yet. Often
this is about the model reading something out of the stash or other
context information (current language, for example).

If you use the context object in your component you have tied it to an
existing request.  This means that you might get into problems when
you try to use the component (e.g. the model - the most common case)
outside of Catalyst, for example in cronjobs.

A stable solution to this problem is to design the Catalyst model
separately from the underlying model logic. Let's take
L<Catalyst::Model::DBIC::Schema> as an example. You can create a
schema outside of Catalyst that knows nothing about the web. This kind
of design ensures encapsulation and makes development and maintenance
a whole lot easier. The you use the aforementioned model to tie your
schema to your application. This gives you a C<MyApp::DBIC> (the name
is of course just an example) model as well as
C<MyApp::DBIC::TableName> models to access your result sources
directly.

By creating such a thin layer between the actual model and the
Catalyst application, the schema itself is not at all tied to any
application and the layer in-between can access the model's API using
information from the context object.

A Catalyst component accesses the context object at request time with
L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.

=head1 設定(CONFIGURATION)

The application has to interact with the extension with some
configuration. There is of course again more than one way to do it.

=head2 アトリビュート(Attributes)

You can specify any valid Perl attribute on Catalyst actions you like.
(See L<attributes/"Syntax of Attribute Lists"> for a description of
what is valid.) These will be available on the C<Catalyst::Action>
instance via its C<attributes> accessor. To give an example, this
action:

  sub foo : Local Bar('Baz') {
      my ($self, $c) = @_;
      my $attributes =
      $self->action_for('foo')->attributes;
      $c->res->body($attributes->{Bar}[0] );
  }

will set the response body to C<Baz>. The values always come in an
array reference. As you can see, you can use attributes to configure
your actions. You can specify or alter these attributes via
L</"Component Configuration">, or even react on them as soon as
Catalyst encounters them by providing your own L<component base
class|/"Component Base Classes">.

=head2 カスタムアクセサをつくる(Creating custom accessors)

L<Catalyst::Component> uses L<Class::Accessor::Fast> for accessor
creation. Please refer to the modules documentation for usage
information.

L<Catalyst::Component> はアクセサをつくるのに L<Class::Accessor::Fast> をつかって
います。

=head2 コンポーネントの設定(Component configuration)

At creation time, the class configuration of your component (the one
available via C<$self-E<gt>config>) will be merged with possible
configuration settings from the applications configuration (either
directly or via config file).  This is then stored in the controller
object's hash reference. So, if you read possible configurations like:

  my $model_name = $controller->{model_name};

you will get the right value. The C<config> accessor always only
contains the original class configuration and must not be used for
component configuration.

You are advised to create accessors on your component class for your
configuration values. This is good practice and makes it easier to
capture configuration key typos. You can do this with the
C<mk_ro_accessors> method provided to L<Catalyst::Component> via
L<Class::Accessor::Fast>:

  use base 'Catalyst::Controller';
  __PACKAGE__->mk_ro_accessors('model_name');
  ...
  my $model_name = $controller->model_name;

=head1 実装(IMPLEMENTATION)

This part contains the technical details of various implementation
methods. Please read the L</"BEST PRACTICES"> before you start your
implementation, if you haven't already.

=head2 Actionクラス(Action classes)

Usually, your action objects are of the class L<Catalyst::Action>.
You can override this with the C<ActionClass> attribute to influence
execution and/or dispatching of the action. A widely used example of
this is L<Catalyst::Action::RenderView>, which is used in every newly
created Catalyst application in your root controller:

  sub end : ActionClass('RenderView') { }

Usually, you want to override the C<execute> and/or the C<match>
method. The execute method of the action will naturally call the
methods code. You can surround this by overriding the method in a
subclass:

  package Catalyst::Action::MyFoo; use strict;

  use Class::C3; use base 'Catalyst::Action';

  sub execute {
      my $self = shift;
      my ($controller, $c, @args) = @_;
      # put your 'before' code here
      my $r = $self->next::method(@_);
      # put your 'after' code here
      return $r;
  }
  1;

We are using L<Class::C3> to re-dispatch to the original C<execute> method
in the L<Catalyst::Action> class.

The Catalyst dispatcher handles an incoming request and, depending
upon the dispatch type, will call the appropriate target or chain. 
From time to time it asks the actions themselves, or through the
controller, if they would match the current request. That's what the
C<match> method does.  So by overriding this, you can change on what
the action will match and add new matching criteria.

For example, the action class below will make the action only match on
Mondays:

  package Catalyst::Action::OnlyMondays; use strict;

  use Class::C3;
  use base 'Catalyst::Action';

  sub match {
      my $self = shift;
      return 0 if ( localtime(time) )[6] == 1;
      return $self->next::method(@_);
   }
  1;

And this is how we'd use it:

  sub foo: Local ActionClass('OnlyMondays') {
      my ($self, $c) = @_;
      $c->res->body('I feel motivated!');
  }

If you are using action classes often or have some specific base
classes that you want to specify more conveniently, you can implement
a component base class providing an attribute handler.

For further information on action classes, please refer to
L<Catalyst::Action> and L<Catalyst::Manual::Actions>.

=head2 コンポーネントなクラス(Component base classes)

Many L<Catalyst::Plugin> that were written in Catalyst's early days
should really have been just controller base classes. With such a
class, you could provide functionality scoped to a single controller,
not polluting the global namespace in the context object.

Catalyst がうまれたての頃に多くの L<Catalyst::Plugin> が書かれました。

You can provide regular Perl methods in a base class as well as
actions which will be inherited to the subclass. Please refer to
L</Controllers> for an example of this.

You can introduce your own attributes by specifying a handler method
in the controller base. For example, to use a C<FullClass> attribute
to specify a fully qualified action class name, you could use the
following implementation. Note, however, that this functionality is
already provided via the C<+> prefix for action classes. A simple

シンプルな

  sub foo : Local ActionClass('+MyApp::Action::Bar') { ... }

will use C<MyApp::Action::Bar> as action class.

は、C<MyApp::Action::Bar> を Action クラスとしてつかいます。

  package MyApp::Base::Controller::FullClass; use strict; use base
  'Catalyst::Controller';

  sub _parse_FullClass_attr {
      my ($self, $app_class, $action_name, $value, $attrs) = @_;
      return( ActionClass => $value );
  }
  1;

Note that the full line of arguments is only provided for completeness
sake. We could use this attribute in a subclass like any other
Catalyst attribute:

  package MyApp::Controller::Foo;
  use strict;
  use base 'MyApp::Base::Controller::FullClass';

  sub foo : Local FullClass('MyApp::Action::Bar') { ... }

  1;

=head2 コントローラ(Controllers)

Many things can happen in controllers, and it often improves
maintainability to abstract some of the code out into reusable base
classes.

You can provide usual Perl methods that will be available via your
controller object, or you can even define Catalyst actions which will
be inherited by the subclasses. Consider this controller base class:

  package MyApp::Base::Controller::ModelBase;
  use strict;
  use base 'Catalyst::Controller';

  sub list : Chained('base') PathPart('') Args(0) {
      my ($self, $c) = @_;
      my $model = $c->model( $self->{model_name} );
      my $condition = $self->{model_search_condition} || {};
      my $attrs = $self->{model_search_attrs} || {};
      $c->stash(rs => $model->search($condition, $attrs);
      }

  sub load : Chained('base') PathPart('') CaptureArgs(1) {
      my ($self, $c, $id) = @_;
      my $model = $c->model( $self->{model_name} );
      $c->stash(row => $model->find($id));
      }
  1;

This example implements two simple actions. The C<list> action chains
to a (currently non-existent) C<base> action and puts a result-set
into the stash taking a configured C<model_name> as well as a search
condition and attributes. This action is a
L<chained|Catalyst::DispatchType::Chained> endpoint. The other action,
called C< load > is a chain midpoint that takes one argument. It takes
the value as an ID and loads the row from the configured model. Please
not that the above code is simplified for clarity. It misses error
handling, input validation, and probably other things.

The class above is not very useful on its own, but we can combine it
with some custom actions by sub-classing it:

  package MyApp::Controller::Foo;
  use strict;
  use base 'MyApp::Base::Controller::ModelBase';

  __PACKAGE__->config( model_name => 'DB::Foo',
                       model_search_condition=> { is_active => 1 },
                       model_search_attrs => { order_by => 'name' },
                   );

  sub base : Chained PathPart('foo') CaptureArgs(0) { }

  sub view : Chained('load') Args(0) {
      my ($self, $c) = @_;
      my $row = $c->stash->{row};
      $c->res->body(join ': ', $row->name,
      $row->description); }
  1;

This class uses the formerly created controller as a base
class. First, we see the configurations that were used in the parent
class. Next comes the C<base> action, where everything chains off of.

Note that inherited actions act like they were declared in your
controller itself. You can therefor call them just by their name in
C<forward>s, C<detaches> and C<Chained(..)> specifications. This is an
important part of what makes this technique so useful.

The new C<view> action ties itself to the C<load> action specified in
the base class and outputs the loaded row's C<name> and C<description>
columns. The controller C<MyApp::Controller::Foo> now has these
publicly available paths:

=over

=item /foo

Will call the controller's C<base>, then the base classes C<list>
action.

=item /foo/$id/view

First, the controller's C<base> will be called, then it will C<load>
the row with the corresponding C<$id>. After that, C<view> will
display some fields out of the object.

=back

=head2 モデルとビュー(Models and Views)

If the functionality you'd like to add is really a data-set that you
want to manipulate, for example internal document types, images,
files, it might be better suited as a model.

The same applies for views. If your code handles representation or
deals with the applications interface and should be universally
available, it could be a perfect candidate for a view.

Please implement a C<process> method in your views. This method will
be called by Catalyst if it is asked to forward to a component without
a specified action. Note that C<process> is B<not a Catalyst action>
but a simple Perl method.

You are also encouraged to implement a C<render> method corresponding
with the one in L<Catalyst::View::TT>. This has proven invaluable,
because people can use your view for much more fine-grained content
generation.

Here is some example code for a fictional view:

  package CatalystX::View::MyView;
  use strict;
  use base 'Catalyst::View';

  sub process {
      my ($self, $c) = @_;
      my $template = $c->stash->{template};
      my $content = $self->render($c, $template, $c->stash);
      $c->res->body( $content );
  }

  sub render {
      my ($self, $c, $template, $args) = @_;
      # prepare content here
      return $content;
  }
  1;

=head2 プラグイン(Plugins)

The first thing to say about plugins is that if you're not sure if
your module should be a plugin, it probably shouldn't. It once was
common to add features to Catalyst by writing plugins that provide
accessors to said functionality. As Catalyst grew more popular, it
became obvious that this qualifies as bad practice.

まずもって、あなたがプラグインをつくろうとおもっている場合、十中八九プラグインを
つくるべきではありません。

By designing your module as a Catalyst plugin, every method you
implement, import or inherit will be available via your applications
context object.  A plugin pollutes the global namespace, and you
should be only doing that when you really need to.

あなたのモジュールを Catalyst のプラグインとして実装した場合、あなたが実装したす
べてのメソッドはあなたのアプリケーションの context object に継承されます。プラグ
インはグローバルなネームスペースをけがします。あなたはほんとうにそうしたいときに
だけそうするべきです。

Often, developers design extensions as plugins because they need to
get hold of the context object. Either to get at the stash or
request/response objects are the widely spread reasons. It is,
however, perfectly possible to implement a regular Catalyst component
(read: model, view or controller) that receives the current context
object via L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.

When is a plugin suited to your task? Your code needs to be a
plugin to act upon or alter specific parts of Catalyst's request
lifecycle. If your functionality needs to wrap some C<prepare_*> or
C<finalize_*> stages, you won't get around a plugin.

Another valid target for a plugin architecture are things that
B<really> have to be globally available, like sessions or
authentication.

B<Please do not> release Catalyst extensions as plugins only to
provide some functionality application wide. Design it as a controller
base class or another suiting technique with a smaller scope, so that
your code only influences those parts of the application where it is
needed, and namespace clashes and conflicts are ruled out.

The implementation is pretty easy. Your plugin will be inserted in the
application's inheritance list, above Catalyst itself. You can by this
alter Catalyst's request lifecycle behaviour. Every method you
declare, every import in your package will be available as method on
the application and the context object. As an example, let's say you
want Catalyst to warn you every time uri_for returned an undefined
value, for example because you specified the wrong number of captures
for the targeted action chain. You could do this with this simple
implementation (excuse the lame class name, it's just an example):

プラグインの実装は簡単なようにみえます。あなたのプラグインは Catalyst の継承ツリー
の上にはいります。これによりあなたは、Catalyst のリクエストライフサイクルの挙動を
変えることができます。あなたが定義したりあなたのパッケージに import したメソッド
は、すべてアプリケーションとコンテキストオブジェクトにはえます。例としてあなたが
Catalyst に uri_for の返り値が undef だったとき警告をだすプラグインをつくったとし
ましょう。(中略)(アホみたいなクラス名ですいません。これは例なので勘弁してね)

  package Catalyst::Plugin::UriforUndefWarning;
  use strict;
  use Class::C3;

  sub uri_for {
      my $c = shift;
      my $uri = $c->next::method(@_);
      $c->log->warn( 'uri_for returned undef for:', join(', ', @_), );
      return $uri;
  }

  1;

This would override Catalyst's C<uri_for> method and emit a C<warn>
log entry containing the arguments that led to the undefined return
value.

これは Catalyst の C<uri_for> メソッドをうわがきし、undef がかえってきたら警告を
ログに吐きだします。

=head2 COMPONENT() をつかってコンポーネントを生成する(Factory components with COMPONENT())

Every component inheriting from L<Catalyst::Component> contains a
C<COMPONENT> method. It is used on application startup by
C<setup_components> to instantiate the component object for the
Catalyst application. By default, this will merge the components own
C<config>uration with the application wide overrides and call the
class' C<new> method to return the component object.

L<Catalyst::Component> を継承しているすべてのコンポーネントは C<COMPONENT> メソッ
ドをもっています。

You can override this method and do and return whatever you want.
However, you should use L<Class::C3> to forward to the original
C<COMPONENT> method to merge the configuration of your component.

Here is a stub C<COMPONENT> method:

  package CatalystX::Component::Foo;
  use strict;
  use base 'Catalyst::Component';

  use Class::C3;

  sub COMPONENT {
      my $class = shift;
      my ($app_class, $config) = @_;

      # do things here before instantiation my
      $obj = $self->next::method(@_);
      # do things to object after instantiation
      return $object;
  }

The arguments are the class name of the component, the class name of
the application instantiating the component, and a hash reference with
the controller's configuration.

You are free to re-bless the object, instantiate a whole other
component or really do anything compatible with Catalyst's
expectations on a component.

For more information, please see L<Catalyst::Component/"COMPONENT($c,$arguments)">.

=head1 SEE ALSO

L<Catalyst>, L<Catalyst::Manual::Actions>, L<Catalyst::Component>

=head1 AUTHOR

Robert Sedlacek C<< <rs@474.at> >>

Jonathan Rockway C<< <jrockway@cpan.org> >>

=head1 LICENSE AND COPYRIGHT

This document is free, you can redistribute it and/or modify it under
the same terms as Perl itself.

=cut