Re^3: package compiling

Add ...

use strict;
use warnings;
[download]

... and perhaps ...

use 5.008_003;
[download]

(because older perls may have older Exporters), then the code looks quite good.

Next step is to think about stopping exporting without explicit request (i.e. move exports from @EXPORT to @EXPORT_OK, think about %EXPORT_TAGS, learn about tag handling utility functions in Exporter).

Then, you could re-think your design. Do you really need to export a variable? Perhaps an object is a much better solution for your problem.

On the other hand, sometimes exporting a variable is the best solution. In some situations, exporting it by default is even better than exporting on demand.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^3: package compiling Select or Download Code

Replies are listed 'Best First'.
Re^4: package compiling by Anonymous Monk on Apr 22, 2011 at 11:56 UTC
I'm sure I read somewhere that OO in Perl can slow down compilation and execution time by upto 40%... is that right? What advantage would there to be gained from objectifying the code when all its meant to do really is act as a config file that doesn't need the processing overhead of parsing XML? I ask in earnest, as I often wonder what people see in OO and why it seems to be taking over every language.	[reply]
Re^5: package compiling by afoken (Chancellor) on Apr 22, 2011 at 15:57 UTC
I'm sure I read somewhere that OO in Perl can slow down compilation and execution time by upto 40%... is that right? Sure, somewhere in a Java or Python forum ... ;-) OOP has a little overhead, but 40% looks like a very constructed example. And "up to 40%" could also mean zero. If you want to know, run benchmarks. If you want to know why your code is slow, use Devel::NYTProf. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]