Re^2: Inheritance

@EXPORT instead of @EXPORT_OK, which works, but which will make debugging much harder

This is not related to debugging.

The difference is that subs and vars included in @EXPORT will always be exported to the modules use'ing the module, while on the other hand, things included on @EXPORT_OK will only be exported when explicitely requested on the use statement.

The problem with @EXPORT is namespace pollution that leads to name collisions when exported functions are added in new versions of some module.

Comment on Re^2: Inheritance Select or Download Code

Replies are listed 'Best First'.
Re^3: Inheritance by tilly (Archbishop) on Jun 04, 2005 at 03:11 UTC
There is also a debugging problem. Two of them in fact. The first debugging problem is figuring out what happened after name collisions. (Creating bugs leads to debugging...) The second, and to me more important, one is the added trouble in finding the functions and variables that you see being called and accessed.	[reply]
Re^3: Inheritance by fishbot_v2 (Chaplain) on Jun 04, 2005 at 03:17 UTC
The difference is that subs and vars included in @EXPORT will always* be exported to the modules use'ing the module...* Not to be overly retentive here, but that's not quite right. Or at least not sufficiently clear. In the empty list case - `use Some::Module ();` - no symbols are exported, even the ones in `@EXPORT`. In fact, `@EXPORT` are only imported in the default (unspecified) case. If you specify your imports explicitly, then you only get what you ask for.	[reply] [d/l] [select]