Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8814
| Newsgroups | comp.lang.perl.misc |
|---|---|
| Subject | Re: using Exporter::export_fail |
| References | <51ec36ff$0$6548$9b4e6d93@newsspool4.arcor-online.net> <51ec5a7b$0$6562$9b4e6d93@newsspool4.arcor-online.net> <7rivba-e0c1.ln1@anubis.morrow.me.uk> <51ed77a8$0$6581$9b4e6d93@newsspool3.arcor-online.net> |
| From | Ben Morrow <ben@morrow.me.uk> |
| Organization | morrow.me.uk |
| Date | 2013-07-22 22:41 +0100 |
| Message-ID | <vhl0ca-euf1.ln1@anubis.morrow.me.uk> (permalink) |
Quoth "A. Sicken" <AndSiPerl@Arcor.De>:
> Ben Morrow wrote:
>
> > I don't understand what you mean here. If you're currently using
> > Exporter::import then writing your own import method which calls
> > Exporter->export_to_level(1, @exports) will do the same thing.
> Sorry my fault. Most modules work like connectors and they are somehow aware
> what to do. For example: I have written two modules - one
> (Ext::Data::Object::Float) does stuff like defining what a float number
> should look alike (size, precision, minimum and many things more) - the
> other (PgSerializer) stuff things into an Postgres-Table and or Database.
> Now if you define a Float-object and provide it to PGSerializer it will use
> the given definitions to create a fitting table - even SQL-constraints. Same
> goes for a String object. But if you provide an PgSerializer object to a
> Float object (Ex. Ext::Data::Object::Float->new($PgSerializer) ) it will
> simply create a Float object with meating definitions.
> For both objects exists a dumper class: If you call that with Float it will
> behave in default menor (writing some xml) but if you put the Float object
> wrapped in PgSerializer in it, it will pass handling the stuff to
> PgSerializer.
> In short you can call them nested and depending on how they are nested you
> get functionality.
> This works because of a well defined object and method api that carry
> required information. One leg to it is to reuse code (where inheritance come
> in).
I don't see what any of that has to do with exporting. If you replace
use Exporter "import";
with
require Exporter;
sub import {
my ($from, @args) = @_;
my $to = caller;
my @syms = grep $_ ne "enable_debug", @args;
if (@syms != @args) {
# enable global debugging
}
$from->Exporter::export($to, @syms);
}
I believe it will do exactly what you want. Of course, any subclasses
which inherit this import method will also support the 'enable_debug'
option; if that's a problem then either don't make the base class the
one that supports the option, or, as Rainer says, check $from to make
sure this is 'your' import method.
(Rereading the docs and source of Exporter, export_to_level only works
if you inherit from Exporter. ->export works without inheritance, as
long as you call it like that.)
> > export_fail is called from Exporter::export, which is called from
> > Exporter::import or Exporter::export_to_level.
> I need a run-state like exporter is called right after its own begin-blocks
> but before your modul begin-blocks. In that case I can simply use a begin-
> block to override or delete my own eport_fail method and resolve any
> depending problem at once...
Sorry, what? The whole of your module file (including any BEGIN blocks)
is compiled and run before perl even attempts to call the import
method...
> So far I haven't found information about when export is called.
I just told you. Exporter::import and Exporter::export_to_level both
call Exporter::export to do the actual exporting.
[Well, there's some gnarly special-casing of simple cases, but that
doesn't apply here. And export_to_level actually calls the exported-from
package's ->export method, and expects it to inherit from Exporter.]
Or do you mean when import is called?
use Foo @args;
is exactly equivalent to
BEGIN {
require Foo;
Foo->import(@args);
}
Ben
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Next in thread | Find similar
using Exporter::export_fail "A. Sicken" <AndSiPerl@Arcor.De> - 2013-07-21 21:31 +0200
Re: using Exporter::export_fail Ben Morrow <ben@morrow.me.uk> - 2013-07-21 21:23 +0100
Re: using Exporter::export_fail "A. Sicken" <AndSiPerl@Arcor.De> - 2013-07-22 00:02 +0200
Re: using Exporter::export_fail Ben Morrow <ben@morrow.me.uk> - 2013-07-22 12:49 +0100
Re: using Exporter::export_fail "A. Sicken" <AndSiPerl@Arcor.De> - 2013-07-22 20:19 +0200
Re: using Exporter::export_fail Ben Morrow <ben@morrow.me.uk> - 2013-07-22 22:41 +0100
Re: using Exporter::export_fail Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-22 14:55 +0100
Re: using Exporter::export_fail "A. Sicken" <AndSiPerl@Arcor.De> - 2013-07-22 19:42 +0200
Re: using Exporter::export_fail Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-22 19:47 +0100
Re: using Exporter::export_fail - SOLVED "A. Sicken" <AndSiPerl@Arcor.De> - 2013-07-22 23:33 +0200
Re: using Exporter::export_fail - SOLVED Ben Morrow <ben@morrow.me.uk> - 2013-07-23 00:14 +0100
csiph-web