Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.perl.misc > #8814

Re: using Exporter::export_fail

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)

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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