Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8806
| 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) |
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 | 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