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


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

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> <pjstba-u641.ln1@anubis.morrow.me.uk> <51ec5a7b$0$6562$9b4e6d93@newsspool4.arcor-online.net>
From Ben Morrow <ben@morrow.me.uk>
Organization morrow.me.uk
Date 2013-07-22 12:49 +0100
Message-ID <7rivba-e0c1.ln1@anubis.morrow.me.uk> (permalink)

Show all headers | View raw


Quoth "A.  Sicken" <AndSiPerl@Arcor.De>:
> Ben Morrow wrote:
> 
> > No. If you must, you can get rid of the method on it's first invocation
> > by deleting the glob from the symbol table, but I wouldn't recommend
> > doing that.
> > 
> > You could alternatively write your own import method, which removes
> > enable_debug from the symbol list and calls Exporter->export_to_level to
> > do the actual exporting.
> > 
> 
> Ok. The method I want to get rid of is the export_fail-method (not the local 
> tied enable_debug var or the symbol) because you can call it on every object 
> created through this modul. Manipulation of the glob-table is a messy job 
> and very error prone; and it does not take modul inheritance into account.

I agree it's a bad idea.

> The other way around (for inheritance only) I guess would be to write 
> export_fail-stubs for every single modul (currently about 20) which is also 
> a messy job :-( - and it would make it worse - because then every modul 
> would need to have an export_fail method which is completely unneccessary 
> for the object stuff.

This package you are exporting from is a base class? Certainly, that
would be messy.

Incidentally, are you inheriting from Exporter or importing its import
method? If you are inheriting then you've just scquired a whole lot of
methods anyway.

> Somehow I was hoping to scope the usage to a BEGIN{} block, so it will 
> invoked only once and then goes out of scope. The real annoying thing is
> that the objects itself have debugging capability for their state and 
> contents whereas the debugging I reffered to is to trace the methods in a 
> certain module itself and I need this functionallity because of the very 
> nature of frameworks and their deep nested calling stack.

A further alternative would be not to use a 'use' parameter at all but
simply to provide a function or method to turn this debugging on. Given
that it has global effect, I doubt you'll want to do this very often.

> To use the export_to_level method isn't an option so far to me because I do 
> not know where to export; a caller based reference doesn't work all the 
> time, so I have to inspect @ISA to find the modul where to export to.

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.

> It seems a long way to go und feels frustrating.

Is any of this important? Does it actually matter that your objects have
an extra method? After all, they have a useless 'import' method already.

> Do you have any knowlege about fitting cpan modules or maybe 
> references/links where I can search for.

There are other Exporters on CPAN; possible one will do what you want.

> EDIT: Maybe I am thinking in the wrong direction! When is the export_fail 
> method called? Before or after any BEGIN-block? Or is there any run-state 
> that can be called right after export_fail (as hook for example)?

export_fail is called from Exporter::export, which is called from
Exporter::import or Exporter::export_to_level.

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