perl/perl-Import-Into
SHA256
9
0
Fork 0
forked from pool/perl-Import-Into
Code Pull Requests Activity

Accepting request 227173 from devel:languages:perl

Browse Source 
update

OBS-URL: https://build.opensuse.org/request/show/227173
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/perl-Import-Into?expand=0&rev=3
This commit is contained in:
Stephan Kulow
2014-03-25 12:25:32 +00:00
committed by Git OBS Bridge
parent c090194c1d 6fc8967bd6
commit dbd18aada4
4 changed files with 18 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Import-Into-1.001001.tar.gz
View File

@@ -1,3 +0,0 @@
version https://git-lfs.github.com/spec/v1
oid sha256:e51b427bb394e43cbcba7965a74f1291cc15de22dc88e456a51f3e591fed12f4
size 4846

3
Import-Into-1.002001.tar.gz Normal file
View File

@@ -0,0 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:245ea6c8aacb39f942d71a445d539216fbdf2b281ea22a92abccf53cf7ecf28f
size 6553

8
perl-Import-Into.changes
View File

@@ -1,3 +1,11 @@
-------------------------------------------------------------------
Sat Mar 22 19:05:03 UTC 2014 - coolo@suse.com
- updated to 1.002001
- fix tests and Makefile.PL to support perl 5.6
- allow specifying by caller level, as well as specifying file, line,
and version
-------------------------------------------------------------------
Thu Aug 1 13:49:28 UTC 2013 - coolo@suse.com

106
perl-Import-Into.spec
View File

@@ -1,7 +1,7 @@
#
# spec file for package perl-Import-Into
#
# Copyright (c) 2013 SUSE LINUX Products GmbH, Nuernberg, Germany.
# Copyright (c) 2014 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@@ -17,21 +17,18 @@
Name: perl-Import-Into
Version: 1.001001
Version: 1.002001
Release: 0
%define cpan_name Import-Into
Summary: import packages into other packages
License: Artistic-1.0 or GPL-1.0+
Group: Development/Libraries/Perl
Url: http://search.cpan.org/dist/Import-Into/
Source: http://www.cpan.org/authors/id/E/ET/ETHER/%{cpan_name}-%{version}.tar.gz
Source: http://www.cpan.org/authors/id/H/HA/HAARG/%{cpan_name}-%{version}.tar.gz
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildRequires: perl
BuildRequires: perl-macros
#BuildRequires: perl(Distar)
#BuildRequires: perl(Import::Into)
#BuildRequires: perl(MultiExporter)
%{perl_requires}
%description
@@ -39,100 +36,11 @@ Writing exporters is a pain. Some use the Exporter manpage, some use the
Sub::Exporter manpage, some use the Moose::Exporter manpage, some use the
Exporter::Declare manpage ... and some things are pragmas.
If you want to re-export other things, you have to know which is which. the
Exporter manpage subclasses provide export_to_level, but if they overrode
their import method all bets are off. the Sub::Exporter manpage provides an
into parameter but figuring out something used it isn't trivial. Pragmas
need to have their 'import' method called directly since they affect the
current unit of compilation.
Exporting on someone else's behalf is harder. The exporters don't provide a
consistent API for this, and pragmas need to have their import method
called directly, since they effect the current unit of compilation.
It's ... annoying.
However, there is an approach that actually works for all of these types.
eval "package $target; use $thing;"
will work for anything checking caller, which is everything except pragmas.
But it doesn't work for pragmas - pragmas need:
$thing->import;
because they're designed to affect the code currently being compiled - so
within an eval, that's the scope of the eval itself, not the module that
just 'use'd you - so
sub import {
eval "use strict;"
}
doesn't do what you wanted, but
sub import {
strict->import;
}
will apply the strict manpage to the calling file correctly.
Of course, now you have two new problems - first, that you still need to
know if something's a pragma, and second that you can't use either of these
approaches alone on something like the Moose manpage or the Moo manpage
that's both an exporter and a pragma.
So, the complete solution is:
my $sub = eval "package $target; sub { shift->import(\@_) }";
$sub->($thing, @import_args);
which means that import is called from the right place for pragmas to take
effect, and from the right package for caller checking to work - and so
behaves correctly for all types of exporter, for pragmas, and for hybrids.
Remembering all this, however, is excessively irritating. So I wrote a
module so I didn't have to anymore. Loading the Import::Into manpage
creates a global method 'import::into' which you can call on any package to
import it into another package. So now you can simply write:
use Import::Into;
$thing->import::into($target, @import_args);
This works because of how perl resolves method calls - a call to a simple
method name is resolved against the package of the class or object, so
$thing->method_name(@args);
is roughly equivalent to:
my $code_ref = $thing->can('method_name');
$code_ref->($thing, @args);
while if a '::' is found, the lookup is made relative to the package name
(i.e. everything before the last '::') so
$thing->Package::Name::method_name(@args);
is roughly equivalent to:
my $code_ref = Package::Name->can('method_name');
$code_ref->($thing, @args);
So since the Import::Into manpage defines a method 'into' in package
'import' the syntax reliably calls that.
For more craziness of this order, have a look at the article I wrote at the
http://shadow.cat/blog/matt-s-trout/madness-with-methods manpage which
covers coderef abuse and the '${\...}' syntax.
Final note: You do still need to ensure that you already loaded '$thing' -
if you're receiving this from a parameter, I recommend using the
Module::Runtime manpage:
use Import::Into;
use Module::Runtime qw(use_module);
use_module($thing)->import::into($target, @import_args);
And that's it.
'Import::Into' provides global methods to make this painless.
%prep
%setup -q -n %{cpan_name}-%{version}