http://www.perlmonks.org?node_id=930394


in reply to Stopping a package from infesting my namespace

Well, how about "mess with" instead of "mess up"? Redefine package Parse::Token::exportTo with your own replacement.

First make sure the original gets read in. Then just define it yourself. Hopefully Parse::Token doesn't do anything at compile time that requires it to be compiled in a specific order.

require Parse::Token; { # turn off warnings to avoid "Subroutine exportTo redefined" message no warnings; package Parse::Token; sub exportTo { ... } } package myPackage; ...

I don't know enough (read: anything at all) about Perse::Lex to know how much messing you can get away with, but it sounds like you've already figured out most of that. It looks like Parse::Token::exportTo() only uses object data and nothing lexically scoped in the module, so at least that won't be a limiting factor.

--Dave

Replies are listed 'Best First'.
Re^2: Stopping a package from infesting my namespace
by anneli (Pilgrim) on Oct 08, 2011 at 23:37 UTC

    Not bad! Thanks for your suggestion! I gave that a go; unfortunately it looks like Parse::Lex depends on those syms being there, and I hacked at it for quite some time without convincing it that they should be elsewhere. (I'd probably have to study it for some time longer, but the long and short of it is that I'd be monkeypatching a lot more than just exportTo(), so I'll leave it.)

    For now I'll just leave my module non-reentrant, until I work out another way, or maybe switch lexer generator.

    Thanks again!

    Anne

      I guess my question then is are the reused symbols/tokens really a problem, or is it just the warnings? Do the tokens need to be scoped tighter than global to avoid conflict?

      If it's just the warnings, you can turn them off a variety of ways, like using 'use warnings;' (lexically scoped to just your own code) instead of 'perl -w' (global). If you do modify exportTo(), you can also just remove the Carp call. That 'if ($^W)' is just checking to see if warnings are enabled.

      --Dave

        I think it could technically cause an issue because the tokens contain subs which close on the environment around them; if someone used two of the parsers in different contexts, the latter one's state might end up being used for the former, too!

        So far I've tried to 'solve' this just by encapsulating these objects well enough such that they're never exposed to the user, so I deal with these issues in the interface (though the module becomes non-reentrant).