Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
openSUSE:13.1:Update
perl-Import-Into
perl-Import-Into.spec
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
File perl-Import-Into.spec of Package perl-Import-Into
# # spec file for package perl-Import-Into # # Copyright (c) 2013 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 # upon. The license for this file, and modifications and additions to the # file, is the same license as for the pristine package itself (unless the # license for the pristine package is not an Open Source License, in which # case the license is the MIT License). An "Open Source License" is a # license that conforms to the Open Source Definition (Version 1.9) # published by the Open Source Initiative. # Please submit bugfixes or comments via http://bugs.opensuse.org/ # Name: perl-Import-Into Version: 1.001001 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 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 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. 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. %prep %setup -q -n %{cpan_name}-%{version} %build %{__perl} Makefile.PL INSTALLDIRS=vendor %{__make} %{?_smp_mflags} %check %{__make} test %install %perl_make_install %perl_process_packlist %perl_gen_filelist %files -f %{name}.files %defattr(-,root,root,755) %doc Changes README %changelog
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor