KevinSchoenmayer/GseTDDUebungKCLR
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial Commit

Browse Source
This commit is contained in:
Riley Schneider
2025-12-03 16:38:10 +01:00
parent c5e26bf594
commit b732d8d4b5
17680 changed files with 5977495 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1108
database/perl/lib/Sub/Exporter.pm Normal file
View File

File diff suppressed because it is too large Load Diff

308
database/perl/lib/Sub/Exporter/Cookbook.pod Normal file
View File

@@ -0,0 +1,308 @@
# ABSTRACT: useful, demonstrative, or stupid Sub::Exporter tricks
# PODNAME: Sub::Exporter::Cookbook
__END__
=pod
=head1 NAME
Sub::Exporter::Cookbook - useful, demonstrative, or stupid Sub::Exporter tricks
=head1 VERSION
version 0.987
=head1 OVERVIEW
Sub::Exporter is a fairly simple tool, and can be used to achieve some very
simple goals. Its basic behaviors and their basic application (that is,
"traditional" exporting of routines) are described in
L<Sub::Exporter::Tutorial> and L<Sub::Exporter>. This document presents
applications that may not be immediately obvious, or that can demonstrate how
certain features can be put to use (for good or evil).
=head1 THE RECIPES
=head2 Exporting Methods as Routines
With Exporter.pm, exporting methods is a non-starter. Sub::Exporter makes it
simple. By using the C<curry_method> utility provided in
L<Sub::Exporter::Util>, a method can be exported with the invocant built in.
package Object::Strenuous;
use Sub::Exporter::Util 'curry_method';
use Sub::Exporter -setup => {
exports => [ objection => curry_method('new') ],
};
With this configuration, the importing code may contain:
my $obj = objection("irrelevant");
...and this will be equivalent to:
my $obj = Object::Strenuous->new("irrelevant");
The built-in invocant is determined by the invocant for the C<import> method.
That means that if we were to subclass Object::Strenuous as follows:
package Object::Strenuous::Repeated;
@ISA = 'Object::Strenuous';
...then importing C<objection> from the subclass would build-in that subclass.
Finally, since the invocant can be an object, you can write something like
this:
package Cypher;
use Sub::Exporter::Util 'curry_method';
use Sub::Exporter -setup => {
exports => [ encypher => curry_method ],
};
with the expectation that C<import> will be called on an instantiated Cypher
object:
BEGIN {
my $cypher = Cypher->new( ... );
$cypher->import('encypher');
}
Now there is a globally-available C<encypher> routine which calls the encypher
method on an otherwise unavailable Cypher object.
=head2 Exporting Methods as Methods
While exporting modules usually export subroutines to be called as subroutines,
it's easy to use Sub::Exporter to export subroutines meant to be called as
methods on the importing package or its objects.
Here's a trivial (and naive) example:
package Mixin::DumpObj;
use Data::Dumper;
use Sub::Exporter -setup => {
exports => [ qw(dump) ]
};
sub dump {
my ($self) = @_;
return Dumper($self);
}
When writing your own object class, you can then import C<dump> to be used as a
method, called like so:
$object->dump;
By assuming that the importing class will provide a certain interface, a
method-exporting module can be used as a simple plugin:
package Number::Plugin::Upto;
use Sub::Exporter -setup => {
into => 'Number',
exports => [ qw(upto) ],
groups => [ default => [ qw(upto) ] ],
};
sub upto {
my ($self) = @_;
return 1 .. abs($self->as_integer);
}
The C<into> line in the configuration says that this plugin will export, by
default, into the Number package, not into the C<use>-ing package. It can be
exported anyway, though, and will work as long as the destination provides an
C<as_integer> method like the one it expects. To import it to a different
destination, one can just write:
use Number::Plugin::Upto { into => 'Quantity' };
=head2 Mixing-in Complex External Behavior
When exporting methods to be used as methods (see above), one very powerful
option is to export methods that are generated routines that maintain an
enclosed reference to the exporting module. This allows a user to import a
single method which is implemented in terms of a complete, well-structured
package.
Here is a very small example:
package Data::Analyzer;
use Sub::Exporter -setup => {
exports => [ analyze => \'_generate_analyzer' ],
};
sub _generate_analyzer {
my ($mixin, $name, $arg, $col) = @_;
return sub {
my ($self) = @_;
my $values = [ $self->values ];
my $analyzer = $mixin->new($values);
$analyzer->perform_analysis;
$analyzer->aggregate_results;
return $analyzer->summary;
};
}
If imported by any package providing a C<values> method, this plugin will
provide a single C<analyze> method that acts as a simple interface to a more
complex set of behaviors.
Even more importantly, because the C<$mixin> value will be the invocant on
which the C<import> was actually called, one can subclass C<Data::Analyzer> and
replace only individual pieces of the complex behavior, making it easy to write
complex, subclassable toolkits with simple single points of entry for external
interfaces.
=head2 Exporting Constants
While Sub::Exporter isn't in the constant-exporting business, it's easy to
export constants by using one of its sister modules, Package::Generator.
package Important::Constants;
use Sub::Exporter -setup => {
collectors => [ constants => \'_set_constants' ],
};
sub _set_constants {
my ($class, $value, $data) = @_;
Package::Generator->assign_symbols(
$data->{into},
[
MEANING_OF_LIFE => \42,
ONE_TRUE_BASE => \13,
FACTORS => [ 6, 9 ],
],
);
return 1;
}
Then, someone can write:
use Important::Constants 'constants';
print "The factors @FACTORS produce $MEANING_OF_LIFE in $ONE_TRUE_BASE.";
(The constants must be exported via a collector, because they are effectively
altering the importing class in a way other than installing subroutines.)
=head2 Altering the Importer's @ISA
It's trivial to make a collector that changes the inheritance of an importing
package:
use Sub::Exporter -setup => {
collectors => { -base => \'_make_base' },
};
sub _make_base {
my ($class, $value, $data) = @_;
my $target = $data->{into};
push @{"$target\::ISA"}, $class;
}
Then, the user of your class can write:
use Some::Class -base;
and become a subclass. This can be quite useful in building, for example, a
module that helps build plugins. We may want a few utilities imported, but we
also want to inherit behavior from some base plugin class;
package Framework::Util;
use Sub::Exporter -setup => {
exports => [ qw(log global_config) ],
groups => [ _plugin => [ qw(log global_config) ]
collectors => { '-plugin' => \'_become_plugin' },
};
sub _become_plugin {
my ($class, $value, $data) = @_;
my $target = $data->{into};
push @{"$target\::ISA"}, $class->plugin_base_class;
push @{ $data->{import_args} }, '-_plugin';
}
Now, you can write a plugin like this:
package Framework::Plugin::AirFreshener;
use Framework::Util -plugin;
=head2 Eating Exporter.pm's Brain
You probably shouldn't actually do this in production. It's offered more as a
demonstration than a suggestion.
sub exporter_upgrade {
my ($pkg) = @_;
my $new_pkg = "$pkg\::UsingSubExporter";
return $new_pkg if $new_pkg->isa($pkg);
Sub::Exporter::setup_exporter({
as => 'import',
into => $new_pkg,
exports => [ @{"$pkg\::EXPORT_OK"} ],
groups => {
%{"$pkg\::EXPORT_TAG"},
default => [ @{"$pkg\::EXPORTS"} ],
},
});
@{"$new_pkg\::ISA"} = $pkg;
return $new_pkg;
}
This routine, given the name of an existing package configured to use
Exporter.pm, returns the name of a new package with a Sub::Exporter-powered
C<import> routine. This lets you import C<Toolkit::exported_sub> into the
current package with the name C<foo> by writing:
BEGIN {
require Toolkit;
exporter_upgrade('Toolkit')->import(exported_sub => { -as => 'foo' })
}
If you're feeling particularly naughty, this routine could have been declared
in the UNIVERSAL package, meaning you could write:
BEGIN {
require Toolkit;
Toolkit->exporter_upgrade->import(exported_sub => { -as => 'foo' })
}
The new package will have all the same exporter configuration as the original,
but will support export and group renaming, including exporting into scalar
references. Further, since Sub::Exporter uses C<can> to find the routine being
exported, the new package may be subclassed and some of its exports replaced.
=head1 AUTHOR
Ricardo Signes <rjbs@cpan.org>
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2007 by Ricardo Signes.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

280
database/perl/lib/Sub/Exporter/Tutorial.pod Normal file
View File

@@ -0,0 +1,280 @@
# PODNAME: Sub::Exporter::Tutorial
# ABSTRACT: a friendly guide to exporting with Sub::Exporter
__END__
=pod
=head1 NAME
Sub::Exporter::Tutorial - a friendly guide to exporting with Sub::Exporter
=head1 VERSION
version 0.987
=head1 DESCRIPTION
=head2 What's an Exporter?
When you C<use> a module, first it is required, then its C<import> method is
called. The Perl documentation tells us that the following two lines are
equivalent:
use Module LIST;
BEGIN { require Module; Module->import(LIST); }
The method named C<import> is the module's I<exporter>, it exports
functions and variables into its caller's namespace.
=head2 The Basics of Sub::Exporter
Sub::Exporter builds a custom exporter which can then be installed into your
module. It builds this method based on configuration passed to its
C<setup_exporter> method.
A very basic use case might look like this:
package Addition;
use Sub::Exporter;
Sub::Exporter::setup_exporter({ exports => [ qw(plus) ]});
sub plus { my ($x, $y) = @_; return $x + $y; }
This would mean that when someone used your Addition module, they could have
its C<plus> routine imported into their package:
use Addition qw(plus);
my $z = plus(2, 2); # this works, because now plus is in the main package
That syntax to set up the exporter, above, is a little verbose, so for the
simple case of just naming some exports, you can write this:
use Sub::Exporter -setup => { exports => [ qw(plus) ] };
...which is the same as the original example -- except that now the exporter is
built and installed at compile time. Well, that and you typed less.
=head2 Using Export Groups
You can specify whole groups of things that should be exportable together.
These are called groups. L<Exporter> calls these tags. To specify groups, you
just pass a C<groups> key in your exporter configuration:
package Food;
use Sub::Exporter -setup => {
exports => [ qw(apple banana beef fluff lox rabbit) ],
groups => {
fauna => [ qw(beef lox rabbit) ],
flora => [ qw(apple banana) ],
}
};
Now, to import all that delicious foreign meat, your consumer needs only to
write:
use Food qw(:fauna);
use Food qw(-fauna);
Either one of the above is acceptable. A colon is more traditional, but
barewords with a leading colon can't be enquoted by a fat arrow. We'll see why
that matters later on.
Groups can contain other groups. If you include a group name (with the leading
dash or colon) in a group definition, it will be expanded recursively when the
exporter is called. The exporter will B<not> recurse into the same group twice
while expanding groups.
There are two special groups: C<all> and C<default>. The C<all> group is
defined for you and contains all exportable subs. You can redefine it,
if you want to export only a subset when all exports are requested. The
C<default> group is the set of routines to export when nothing specific is
requested. By default, there is no C<default> group.
=head2 Renaming Your Imports
Sometimes you want to import something, but you don't like the name as which
it's imported. Sub::Exporter can rename your imports for you. If you wanted
to import C<lox> from the Food package, but you don't like the name, you could
write this:
use Food lox => { -as => 'salmon' };
Now you'd get the C<lox> routine, but it would be called salmon in your
package. You can also rename entire groups by using the C<prefix> option:
use Food -fauna => { -prefix => 'cute_little_' };
Now you can call your C<cute_little_rabbit> routine. (You can also call
C<cute_little_beef>, but that hardly seems as enticing.)
When you define groups, you can include renaming.
use Sub::Exporter -setup => {
exports => [ qw(apple banana beef fluff lox rabbit) ],
groups => {
fauna => [ qw(beef lox), rabbit => { -as => 'coney' } ],
}
};
A prefix on a group like that does the right thing. This is when it's useful
to use a dash instead of a colon to indicate a group: you can put a fat arrow
between the group and its arguments, then.
use Food -fauna => { -prefix => 'lovely_' };
eat( lovely_coney ); # this works
Prefixes also apply recursively. That means that this code works:
use Sub::Exporter -setup => {
exports => [ qw(apple banana beef fluff lox rabbit) ],
groups => {
fauna => [ qw(beef lox), rabbit => { -as => 'coney' } ],
allowed => [ -fauna => { -prefix => 'willing_' }, 'banana' ],
}
};
...
use Food -allowed => { -prefix => 'any_' };
$dinner = any_willing_coney; # yum!
Groups can also be passed a C<-suffix> argument.
Finally, if the C<-as> argument to an exported routine is a reference to a
scalar, a reference to the routine will be placed in that scalar.
=head2 Building Subroutines to Order
Sometimes, you want to export things that you don't have on hand. You might
want to offer customized routines built to the specification of your consumer;
that's just good business! With Sub::Exporter, this is easy.
To offer subroutines to order, you need to provide a generator when you set up
your exporter. A generator is just a routine that returns a new routine.
L<perlref> is talking about these when it discusses closures and function
templates. The canonical example of a generator builds a unique incrementor;
here's how you'd do that with Sub::Exporter;
package Package::Counter;
use Sub::Exporter -setup => {
exports => [ counter => sub { my $i = 0; sub { $i++ } } ],
groups => { default => [ qw(counter) ] },
};
Now anyone can use your Package::Counter module and he'll receive a C<counter>
in his package. It will count up by one, and will never interfere with anyone
else's counter.
This isn't very useful, though, unless the consumer can explain what he wants.
This is done, in part, by supplying arguments when importing. The following
example shows how a generator can take and use arguments:
package Package::Counter;
sub _build_counter {
my ($class, $name, $arg) = @_;
$arg ||= {};
my $i = $arg->{start} || 0;
return sub { $i++ };
}
use Sub::Exporter -setup => {
exports => [ counter => \'_build_counter' ],
groups => { default => [ qw(counter) ] },
};
Now, the consumer can (if he wants) specify a starting value for his counter:
use Package::Counter counter => { start => 10 };
Arguments to a group are passed along to the generators of routines in that
group, but Sub::Exporter arguments -- anything beginning with a dash -- are
never passed in. When groups are nested, the arguments are merged as the
groups are expanded.
Notice, too, that in the example above, we gave a reference to a method I<name>
rather than a method I<implementation>. By giving the name rather than the
subroutine, we make it possible for subclasses of our "Package::Counter" module
to replace the C<_build_counter> method.
When a generator is called, it is passed four parameters:
=over
=item * the invocant on which the exporter was called
=item * the name of the export being generated (not the name it's being installed as)
=item * the arguments supplied for the routine
=item * the collection of generic arguments
=back
The fourth item is the last major feature that hasn't been covered.
=head2 Argument Collectors
Sometimes you will want to accept arguments once that can then be available to
any subroutine that you're going to export. To do this, you specify
collectors, like this:
package Menu::Airline
use Sub::Exporter -setup => {
exports => ... ,
groups => ... ,
collectors => [ qw(allergies ethics) ],
};
Collectors look like normal exports in the import call, but they don't do
anything but collect data which can later be passed to generators. If the
module was used like this:
use Menu::Airline allergies => [ qw(peanuts) ], ethics => [ qw(vegan) ];
...the consumer would get a salad. Also, all the generators would be passed,
as their fourth argument, something like this:
{ allerges => [ qw(peanuts) ], ethics => [ qw(vegan) ] }
Generators may have arguments in their definition, as well. These must be code
refs that perform validation of the collected values. They are passed the
collection value and may return true or false. If they return false, the
exporter will throw an exception.
=head2 Generating Many Routines in One Scope
Sometimes it's useful to have multiple routines generated in one scope. This
way they can share lexical data which is otherwise unavailable. To do this,
you can supply a generator for a group which returns a hashref of names and
code references. This generator is passed all the usual data, and the group
may receive the usual C<-prefix> or C<-suffix> arguments.
=head1 SEE ALSO
=over 4
=item *
L<Sub::Exporter> for complete documentation and references to other exporters
=back
=head1 AUTHOR
Ricardo Signes <rjbs@cpan.org>
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2007 by Ricardo Signes.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

354
database/perl/lib/Sub/Exporter/Util.pm Normal file
View File

@@ -0,0 +1,354 @@
use strict;
use warnings;
package Sub::Exporter::Util;
{
$Sub::Exporter::Util::VERSION = '0.987';
}
# ABSTRACT: utilities to make Sub::Exporter easier
use Data::OptList ();
use Params::Util ();
sub curry_method {
my $override_name = shift;
sub {
my ($class, $name) = @_;
$name = $override_name if defined $override_name;
sub { $class->$name(@_); };
}
}
BEGIN { *curry_class = \&curry_method; }
sub curry_chain {
# In the future, we can make \%arg an optional prepend, like the "special"
# args to the default Sub::Exporter-generated import routine.
my (@opt_list) = @_;
my $pairs = Data::OptList::mkopt(\@opt_list, 'args', 'ARRAY');
sub {
my ($class) = @_;
sub {
my $next = $class;
for my $i (0 .. $#$pairs) {
my $pair = $pairs->[ $i ];
unless (Params::Util::_INVOCANT($next)) { ## no critic Private
my $str = defined $next ? "'$next'" : 'undef';
Carp::croak("can't call $pair->[0] on non-invocant $str")
}
my ($method, $args) = @$pair;
if ($i == $#$pairs) {
return $next->$method($args ? @$args : ());
} else {
$next = $next->$method($args ? @$args : ());
}
}
};
}
}
# =head2 name_map
#
# This utility returns an list to be used in specify export generators. For
# example, the following:
#
# exports => {
# name_map(
# '_?_gen' => [ qw(fee fie) ],
# '_make_?' => [ qw(foo bar) ],
# ),
# }
#
# is equivalent to:
#
# exports => {
# name_map(
# fee => \'_fee_gen',
# fie => \'_fie_gen',
# foo => \'_make_foo',
# bar => \'_make_bar',
# ),
# }
#
# This can save a lot of typing, when providing many exports with similarly-named
# generators.
#
# =cut
#
# sub name_map {
# my (%groups) = @_;
#
# my %map;
#
# while (my ($template, $names) = each %groups) {
# for my $name (@$names) {
# (my $export = $template) =~ s/\?/$name/
# or Carp::croak 'no ? found in name_map template';
#
# $map{ $name } = \$export;
# }
# }
#
# return %map;
# }
sub merge_col {
my (%groups) = @_;
my %merged;
while (my ($default_name, $group) = each %groups) {
while (my ($export_name, $gen) = each %$group) {
$merged{$export_name} = sub {
my ($class, $name, $arg, $col) = @_;
my $merged_arg = exists $col->{$default_name}
? { %{ $col->{$default_name} }, %$arg }
: $arg;
if (Params::Util::_CODELIKE($gen)) { ## no critic Private
$gen->($class, $name, $merged_arg, $col);
} else {
$class->$$gen($name, $merged_arg, $col);
}
}
}
}
return %merged;
}
sub __mixin_class_for {
my ($class, $mix_into) = @_;
require Package::Generator;
my $mixin_class = Package::Generator->new_package({
base => "$class\:\:__mixin__",
});
## no critic (ProhibitNoStrict)
no strict 'refs';
if (ref $mix_into) {
unshift @{"$mixin_class" . "::ISA"}, ref $mix_into;
} else {
unshift @{"$mix_into" . "::ISA"}, $mixin_class;
}
return $mixin_class;
}
sub mixin_installer {
sub {
my ($arg, $to_export) = @_;
my $mixin_class = __mixin_class_for($arg->{class}, $arg->{into});
bless $arg->{into} => $mixin_class if ref $arg->{into};
Sub::Exporter::default_installer(
{ %$arg, into => $mixin_class },
$to_export,
);
};
}
sub mixin_exporter {
Carp::cluck "mixin_exporter is deprecated; use mixin_installer instead; it behaves identically";
return mixin_installer;
}
sub like {
sub {
my ($value, $arg) = @_;
Carp::croak "no regex supplied to regex group generator" unless $value;
# Oh, qr//, how you bother me! See the p5p thread from around now about
# fixing this problem... too bad it won't help me. -- rjbs, 2006-04-25
my @values = eval { $value->isa('Regexp') } ? ($value, undef)
: @$value;
while (my ($re, $opt) = splice @values, 0, 2) {
Carp::croak "given pattern for regex group generater is not a Regexp"
unless eval { $re->isa('Regexp') };
my @exports = keys %{ $arg->{config}->{exports} };
my @matching = grep { $_ =~ $re } @exports;
my %merge = $opt ? %$opt : ();
my $prefix = (delete $merge{-prefix}) || '';
my $suffix = (delete $merge{-suffix}) || '';
for my $name (@matching) {
my $as = $prefix . $name . $suffix;
push @{ $arg->{import_args} }, [ $name => { %merge, -as => $as } ];
}
}
1;
}
}
use Sub::Exporter -setup => {
exports => [ qw(
like
name_map
merge_col
curry_method curry_class
curry_chain
mixin_installer mixin_exporter
) ]
};
1;
__END__
=pod
=head1 NAME
Sub::Exporter::Util - utilities to make Sub::Exporter easier
=head1 VERSION
version 0.987
=head1 DESCRIPTION
This module provides a number of utility functions for performing common or
useful operations when setting up a Sub::Exporter configuration. All of the
utilities may be exported, but none are by default.
=head1 THE UTILITIES
=head2 curry_method
exports => {
some_method => curry_method,
}
This utility returns a generator which will produce an invocant-curried version
of a method. In other words, it will export a method call with the exporting
class built in as the invocant.
A module importing the code some the above example might do this:
use Some::Module qw(some_method);
my $x = some_method;
This would be equivalent to:
use Some::Module;
my $x = Some::Module->some_method;
If Some::Module is subclassed and the subclass's import method is called to
import C<some_method>, the subclass will be curried in as the invocant.
If an argument is provided for C<curry_method> it is used as the name of the
curried method to export. This means you could export a Widget constructor
like this:
exports => { widget => curry_method('new') }
This utility may also be called as C<curry_class>, for backwards compatibility.
=head2 curry_chain
C<curry_chain> behaves like C<L</curry_method>>, but is meant for generating
exports that will call several methods in succession.
exports => {
reticulate => curry_chain(
new => gather_data => analyze => [ detail => 100 ] => 'results'
),
}
If imported from Spliner, calling the C<reticulate> routine will be equivalent
to:
Spliner->new->gather_data->analyze(detail => 100)->results;
If any method returns something on which methods may not be called, the routine
croaks.
The arguments to C<curry_chain> form an optlist. The names are methods to be
called and the arguments, if given, are arrayrefs to be dereferenced and passed
as arguments to those methods. C<curry_chain> returns a generator like those
expected by Sub::Exporter.
B<Achtung!> at present, there is no way to pass arguments from the generated
routine to the method calls. This will probably be solved in future revisions
by allowing the opt list's values to be subroutines that will be called with
the generated routine's stack.
=head2 merge_col
exports => {
merge_col(defaults => {
twiddle => \'_twiddle_gen',
tweak => \&_tweak_gen,
}),
}
This utility wraps the given generator in one that will merge the named
collection into its args before calling it. This means that you can support a
"default" collector in multiple exports without writing the code each time.
You can specify as many pairs of collection names and generators as you like.
=head2 mixin_installer
use Sub::Exporter -setup => {
installer => Sub::Exporter::Util::mixin_installer,
exports => [ qw(foo bar baz) ],
};
This utility returns an installer that will install into a superclass and
adjust the ISA importing class to include the newly generated superclass.
If the target of importing is an object, the hierarchy is reversed: the new
class will be ISA the object's class, and the object will be reblessed.
B<Prerequisites>: This utility requires that Package::Generator be installed.
=head2 like
It's a collector that adds imports for anything like given regex.
If you provide this configuration:
exports => [ qw(igrep imap islurp exhausted) ],
collectors => { -like => Sub::Exporter::Util::like },
A user may import from your module like this:
use Your::Iterator -like => qr/^i/; # imports igre, imap, islurp
or
use Your::Iterator -like => [ qr/^i/ => { -prefix => 'your_' } ];
The group-like prefix and suffix arguments are respected; other arguments are
passed on to the generators for matching exports.
=head1 AUTHOR
Ricardo Signes <rjbs@cpan.org>
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2007 by Ricardo Signes.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

451
database/perl/lib/Sub/Install.pm Normal file
View File

@@ -0,0 +1,451 @@
use strict;
use warnings;
package Sub::Install;
# ABSTRACT: install subroutines into packages easily
$Sub::Install::VERSION = '0.928';
use Carp;
use Scalar::Util ();
#pod =head1 SYNOPSIS
#pod
#pod use Sub::Install;
#pod
#pod Sub::Install::install_sub({
#pod code => sub { ... },
#pod into => $package,
#pod as => $subname
#pod });
#pod
#pod =head1 DESCRIPTION
#pod
#pod This module makes it easy to install subroutines into packages without the
#pod unsightly mess of C<no strict> or typeglobs lying about where just anyone can
#pod see them.
#pod
#pod =func install_sub
#pod
#pod Sub::Install::install_sub({
#pod code => \&subroutine,
#pod into => "Finance::Shady",
#pod as => 'launder',
#pod });
#pod
#pod This routine installs a given code reference into a package as a normal
#pod subroutine. The above is equivalent to:
#pod
#pod no strict 'refs';
#pod *{"Finance::Shady" . '::' . "launder"} = \&subroutine;
#pod
#pod If C<into> is not given, the sub is installed into the calling package.
#pod
#pod If C<code> is not a code reference, it is looked for as an existing sub in the
#pod package named in the C<from> parameter. If C<from> is not given, it will look
#pod in the calling package.
#pod
#pod If C<as> is not given, and if C<code> is a name, C<as> will default to C<code>.
#pod If C<as> is not given, but if C<code> is a code ref, Sub::Install will try to
#pod find the name of the given code ref and use that as C<as>.
#pod
#pod That means that this code:
#pod
#pod Sub::Install::install_sub({
#pod code => 'twitch',
#pod from => 'Person::InPain',
#pod into => 'Person::Teenager',
#pod as => 'dance',
#pod });
#pod
#pod is the same as:
#pod
#pod package Person::Teenager;
#pod
#pod Sub::Install::install_sub({
#pod code => Person::InPain->can('twitch'),
#pod as => 'dance',
#pod });
#pod
#pod =func reinstall_sub
#pod
#pod This routine behaves exactly like C<L</install_sub>>, but does not emit a
#pod warning if warnings are on and the destination is already defined.
#pod
#pod =cut
sub _name_of_code {
my ($code) = @_;
require B;
my $name = B::svref_2object($code)->GV->NAME;
return $name unless $name =~ /\A__ANON__/;
return;
}
# See also Params::Util, to which this code was donated.
sub _CODELIKE {
(Scalar::Util::reftype($_[0])||'') eq 'CODE'
|| Scalar::Util::blessed($_[0])
&& (overload::Method($_[0],'&{}') ? $_[0] : undef);
}
# do the heavy lifting
sub _build_public_installer {
my ($installer) = @_;
sub {
my ($arg) = @_;
my ($calling_pkg) = caller(0);
# I'd rather use ||= but I'm whoring for Devel::Cover.
for (qw(into from)) { $arg->{$_} = $calling_pkg unless $arg->{$_} }
# This is the only absolutely required argument, in many cases.
Carp::croak "named argument 'code' is not optional" unless $arg->{code};
if (_CODELIKE($arg->{code})) {
$arg->{as} ||= _name_of_code($arg->{code});
} else {
Carp::croak
"couldn't find subroutine named $arg->{code} in package $arg->{from}"
unless my $code = $arg->{from}->can($arg->{code});
$arg->{as} = $arg->{code} unless $arg->{as};
$arg->{code} = $code;
}
Carp::croak "couldn't determine name under which to install subroutine"
unless $arg->{as};
$installer->(@$arg{qw(into as code) });
}
}
# do the ugly work
my $_misc_warn_re;
my $_redef_warn_re;
BEGIN {
$_misc_warn_re = qr/
Prototype\ mismatch:\ sub\ .+? |
Constant subroutine .+? redefined
/x;
$_redef_warn_re = qr/Subroutine\ .+?\ redefined/x;
}
my $eow_re;
BEGIN { $eow_re = qr/ at .+? line \d+\.\Z/ };
sub _do_with_warn {
my ($arg) = @_;
my $code = delete $arg->{code};
my $wants_code = sub {
my $code = shift;
sub {
my $warn = $SIG{__WARN__} ? $SIG{__WARN__} : sub { warn @_ }; ## no critic
local $SIG{__WARN__} = sub {
my ($error) = @_;
for (@{ $arg->{suppress} }) {
return if $error =~ $_;
}
for (@{ $arg->{croak} }) {
if (my ($base_error) = $error =~ /\A($_) $eow_re/x) {
Carp::croak $base_error;
}
}
for (@{ $arg->{carp} }) {
if (my ($base_error) = $error =~ /\A($_) $eow_re/x) {
return $warn->(Carp::shortmess $base_error);
}
}
($arg->{default} || $warn)->($error);
};
$code->(@_);
};
};
return $wants_code->($code) if $code;
return $wants_code;
}
sub _installer {
sub {
my ($pkg, $name, $code) = @_;
no strict 'refs'; ## no critic ProhibitNoStrict
*{"$pkg\::$name"} = $code;
return $code;
}
}
BEGIN {
*_ignore_warnings = _do_with_warn({
carp => [ $_misc_warn_re, $_redef_warn_re ]
});
*install_sub = _build_public_installer(_ignore_warnings(_installer));
*_carp_warnings = _do_with_warn({
carp => [ $_misc_warn_re ],
suppress => [ $_redef_warn_re ],
});
*reinstall_sub = _build_public_installer(_carp_warnings(_installer));
*_install_fatal = _do_with_warn({
code => _installer,
croak => [ $_redef_warn_re ],
});
}
#pod =func install_installers
#pod
#pod This routine is provided to allow Sub::Install compatibility with
#pod Sub::Installer. It installs C<install_sub> and C<reinstall_sub> methods into
#pod the package named by its argument.
#pod
#pod Sub::Install::install_installers('Code::Builder'); # just for us, please
#pod Code::Builder->install_sub({ name => $code_ref });
#pod
#pod Sub::Install::install_installers('UNIVERSAL'); # feeling lucky, punk?
#pod Anything::At::All->install_sub({ name => $code_ref });
#pod
#pod The installed installers are similar, but not identical, to those provided by
#pod Sub::Installer. They accept a single hash as an argument. The key/value pairs
#pod are used as the C<as> and C<code> parameters to the C<install_sub> routine
#pod detailed above. The package name on which the method is called is used as the
#pod C<into> parameter.
#pod
#pod Unlike Sub::Installer's C<install_sub> will not eval strings into code, but
#pod will look for named code in the calling package.
#pod
#pod =cut
sub install_installers {
my ($into) = @_;
for my $method (qw(install_sub reinstall_sub)) {
my $code = sub {
my ($package, $subs) = @_;
my ($caller) = caller(0);
my $return;
for (my ($name, $sub) = %$subs) {
$return = Sub::Install->can($method)->({
code => $sub,
from => $caller,
into => $package,
as => $name
});
}
return $return;
};
install_sub({ code => $code, into => $into, as => $method });
}
}
#pod =head1 EXPORTS
#pod
#pod Sub::Install exports C<install_sub> and C<reinstall_sub> only if they are
#pod requested.
#pod
#pod =head2 exporter
#pod
#pod Sub::Install has a never-exported subroutine called C<exporter>, which is used
#pod to implement its C<import> routine. It takes a hashref of named arguments,
#pod only one of which is currently recognize: C<exports>. This must be an arrayref
#pod of subroutines to offer for export.
#pod
#pod This routine is mainly for Sub::Install's own consumption. Instead, consider
#pod L<Sub::Exporter>.
#pod
#pod =cut
sub exporter {
my ($arg) = @_;
my %is_exported = map { $_ => undef } @{ $arg->{exports} };
sub {
my $class = shift;
my $target = caller;
for (@_) {
Carp::croak "'$_' is not exported by $class" if !exists $is_exported{$_};
install_sub({ code => $_, from => $class, into => $target });
}
}
}
BEGIN { *import = exporter({ exports => [ qw(install_sub reinstall_sub) ] }); }
#pod =head1 SEE ALSO
#pod
#pod =over
#pod
#pod =item L<Sub::Installer>
#pod
#pod This module is (obviously) a reaction to Damian Conway's Sub::Installer, which
#pod does the same thing, but does it by getting its greasy fingers all over
#pod UNIVERSAL. I was really happy about the idea of making the installation of
#pod coderefs less ugly, but I couldn't bring myself to replace the ugliness of
#pod typeglobs and loosened strictures with the ugliness of UNIVERSAL methods.
#pod
#pod =item L<Sub::Exporter>
#pod
#pod This is a complete Exporter.pm replacement, built atop Sub::Install.
#pod
#pod =back
#pod
#pod =head1 EXTRA CREDITS
#pod
#pod Several of the tests are adapted from tests that shipped with Damian Conway's
#pod Sub-Installer distribution.
#pod
#pod =cut
1;
__END__
=pod
=encoding UTF-8
=head1 NAME
Sub::Install - install subroutines into packages easily
=head1 VERSION
version 0.928
=head1 SYNOPSIS
use Sub::Install;
Sub::Install::install_sub({
code => sub { ... },
into => $package,
as => $subname
});
=head1 DESCRIPTION
This module makes it easy to install subroutines into packages without the
unsightly mess of C<no strict> or typeglobs lying about where just anyone can
see them.
=head1 FUNCTIONS
=head2 install_sub
Sub::Install::install_sub({
code => \&subroutine,
into => "Finance::Shady",
as => 'launder',
});
This routine installs a given code reference into a package as a normal
subroutine. The above is equivalent to:
no strict 'refs';
*{"Finance::Shady" . '::' . "launder"} = \&subroutine;
If C<into> is not given, the sub is installed into the calling package.
If C<code> is not a code reference, it is looked for as an existing sub in the
package named in the C<from> parameter. If C<from> is not given, it will look
in the calling package.
If C<as> is not given, and if C<code> is a name, C<as> will default to C<code>.
If C<as> is not given, but if C<code> is a code ref, Sub::Install will try to
find the name of the given code ref and use that as C<as>.
That means that this code:
Sub::Install::install_sub({
code => 'twitch',
from => 'Person::InPain',
into => 'Person::Teenager',
as => 'dance',
});
is the same as:
package Person::Teenager;
Sub::Install::install_sub({
code => Person::InPain->can('twitch'),
as => 'dance',
});
=head2 reinstall_sub
This routine behaves exactly like C<L</install_sub>>, but does not emit a
warning if warnings are on and the destination is already defined.
=head2 install_installers
This routine is provided to allow Sub::Install compatibility with
Sub::Installer. It installs C<install_sub> and C<reinstall_sub> methods into
the package named by its argument.
Sub::Install::install_installers('Code::Builder'); # just for us, please
Code::Builder->install_sub({ name => $code_ref });
Sub::Install::install_installers('UNIVERSAL'); # feeling lucky, punk?
Anything::At::All->install_sub({ name => $code_ref });
The installed installers are similar, but not identical, to those provided by
Sub::Installer. They accept a single hash as an argument. The key/value pairs
are used as the C<as> and C<code> parameters to the C<install_sub> routine
detailed above. The package name on which the method is called is used as the
C<into> parameter.
Unlike Sub::Installer's C<install_sub> will not eval strings into code, but
will look for named code in the calling package.
=head1 EXPORTS
Sub::Install exports C<install_sub> and C<reinstall_sub> only if they are
requested.
=head2 exporter
Sub::Install has a never-exported subroutine called C<exporter>, which is used
to implement its C<import> routine. It takes a hashref of named arguments,
only one of which is currently recognize: C<exports>. This must be an arrayref
of subroutines to offer for export.
This routine is mainly for Sub::Install's own consumption. Instead, consider
L<Sub::Exporter>.
=head1 SEE ALSO
=over
=item L<Sub::Installer>
This module is (obviously) a reaction to Damian Conway's Sub::Installer, which
does the same thing, but does it by getting its greasy fingers all over
UNIVERSAL. I was really happy about the idea of making the installation of
coderefs less ugly, but I couldn't bring myself to replace the ugliness of
typeglobs and loosened strictures with the ugliness of UNIVERSAL methods.
=item L<Sub::Exporter>
This is a complete Exporter.pm replacement, built atop Sub::Install.
=back
=head1 EXTRA CREDITS
Several of the tests are adapted from tests that shipped with Damian Conway's
Sub-Installer distribution.
=head1 AUTHOR
Ricardo SIGNES <rjbs@cpan.org>
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2005 by Ricardo SIGNES.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

153
database/perl/lib/Sub/Util.pm Normal file
View File

@@ -0,0 +1,153 @@
# Copyright (c) 2014 Paul Evans <leonerd@leonerd.org.uk>. All rights reserved.
# This program is free software; you can redistribute it and/or
# modify it under the same terms as Perl itself.
package Sub::Util;
use strict;
use warnings;
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT_OK = qw(
prototype set_prototype
subname set_subname
);
our $VERSION = "1.55";
$VERSION =~ tr/_//d;
require List::Util; # as it has the XS
List::Util->VERSION( $VERSION ); # Ensure we got the right XS version (RT#100863)
=head1 NAME
Sub::Util - A selection of utility subroutines for subs and CODE references
=head1 SYNOPSIS
use Sub::Util qw( prototype set_prototype subname set_subname );
=head1 DESCRIPTION
C<Sub::Util> contains a selection of utility subroutines that are useful for
operating on subs and CODE references.
The rationale for inclusion in this module is that the function performs some
work for which an XS implementation is essential because it cannot be
implemented in Pure Perl, and which is sufficiently-widely used across CPAN
that its popularity warrants inclusion in a core module, which this is.
=cut
=head1 FUNCTIONS
=cut
=head2 prototype
my $proto = prototype( $code )
I<Since version 1.40.>
Returns the prototype of the given C<$code> reference, if it has one, as a
string. This is the same as the C<CORE::prototype> operator; it is included
here simply for symmetry and completeness with the other functions.
=cut
sub prototype
{
my ( $code ) = @_;
return CORE::prototype( $code );
}
=head2 set_prototype
my $code = set_prototype $prototype, $code;
I<Since version 1.40.>
Sets the prototype of the function given by the C<$code> reference, or deletes
it if C<$prototype> is C<undef>. Returns the C<$code> reference itself.
I<Caution>: This function takes arguments in a different order to the previous
copy of the code from C<Scalar::Util>. This is to match the order of
C<set_subname>, and other potential additions in this file. This order has
been chosen as it allows a neat and simple chaining of other
C<Sub::Util::set_*> functions as might become available, such as:
my $code =
set_subname name_here =>
set_prototype '&@' =>
set_attribute ':lvalue' =>
sub { ...... };
=cut
=head2 subname
my $name = subname( $code )
I<Since version 1.40.>
Returns the name of the given C<$code> reference, if it has one. Normal named
subs will give a fully-qualified name consisting of the package and the
localname separated by C<::>. Anonymous code references will give C<__ANON__>
as the localname. If the package the code was compiled in has been deleted
(e.g. using C<delete_package> from L<Symbol>), C<__ANON__> will be returned as
the package name. If a name has been set using L</set_subname>, this name will be
returned instead.
This function was inspired by C<sub_fullname> from L<Sub::Identify>. The
remaining functions that C<Sub::Identify> implements can easily be emulated
using regexp operations, such as
sub get_code_info { return (subname $_[0]) =~ m/^(.+)::(.*?)$/ }
sub sub_name { return (get_code_info $_[0])[0] }
sub stash_name { return (get_code_info $_[0])[1] }
I<Users of Sub::Name beware>: This function is B<not> the same as
C<Sub::Name::subname>; it returns the existing name of the sub rather than
changing it. To set or change a name, see instead L</set_subname>.
=cut
=head2 set_subname
my $code = set_subname $name, $code;
I<Since version 1.40.>
Sets the name of the function given by the C<$code> reference. Returns the
C<$code> reference itself. If the C<$name> is unqualified, the package of the
caller is used to qualify it.
This is useful for applying names to anonymous CODE references so that stack
traces and similar situations, to give a useful name rather than having the
default of C<__ANON__>. Note that this name is only used for this situation;
the C<set_subname> will not install it into the symbol table; you will have to
do that yourself if required.
However, since the name is not used by perl except as the return value of
C<caller>, for stack traces or similar, there is no actual requirement that
the name be syntactically valid as a perl function name. This could be used to
attach extra information that could be useful in debugging stack traces.
This function was copied from C<Sub::Name::subname> and renamed to the naming
convention of this module.
=cut
=head1 AUTHOR
The general structure of this module was written by Paul Evans
<leonerd@leonerd.org.uk>.
The XS implementation of L</set_subname> was copied from L<Sub::Name> by
Matthijs van Duin <xmath@cpan.org>
=cut
1;