|
|
|
| We don't bite newbies here... much | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Cool thread. My latest revelation was about Exporter. I've written some modules that don't need it at all, and I've written some that do need it, in order for a caller script to just use a given function. But it wasn't till a few days ago that I finally learned (or figured out / absorbed / understood) what the difference is between needing Exporter vs. not needing it:
The ones that didn't need Exporter were OO-style; the "ModuleName->new()" or "new ModuleName" method never needs to be explicitly exported, and the returned object reference provides the caller with simple and direct access to the module's methods. The modules that aren't OO-style don't supply that sort of handy object reference, so Exporter is needed in order for the module's function names to be accessible to the caller without the clunky "ModuleName::" prefix. At least, that's how I've come to understand it (finally). I must have known some part of this before (when writing those OO-style modules), but it turns out I don't write modules all that often, and I actually did scratch my head a bit recently when writing a simple "functions-only" module, trying to recall what incantation to use involving Exporter, and seeing that some of my older modules didn't use it at all (yet these never needed the "ModuleName::" syntax when being used). I attribute my surprise to my habitually "procedural" mindset, which Perl supports so effectively. In reply to Re: What I Most Recently Learned in Perl, But Should Have Already Known
by graff
|
|