Dave Rolsky wrote:
There's a lot of value in following the existing best practices of the
Perl community as a whole. For one thing, it means you can hire people
with "Perl experience" and they can bring that experience to bear on
your application.
If you insist on reinventing every wheel, you
On Fri, 14 Mar 2008, Matisse Enzer wrote:
I'm discussing some potential refactorings at $work at wanted to give an
articulate explanation of the benefits of having package declarations match
file names, so that:
# file is Foo/bar.pm
package Foo::Bar;
One reason is so that when you see a "p
On Mar 14, 2008, at 6:53 PM, Michael G Schwern wrote:
Matisse Enzer wrote:
# file is Foo/bar.pm
package Foo::Bar;
That was probably a typo,
Yes, a typo. Sorry to muddy the waters.
Eric already covered the import() issue.
Yes, and thank you Eric - I did not know that.
There's al
Matisse Enzer wrote:
I'm discussing some potential refactorings at $work at wanted to give an
articulate explanation of the benefits of having package declarations
match file names, so that:
# file is Foo/bar.pm
package Foo::Bar;
That was probably a typo, but I hope you mean Foo/Bar.pm
First, ExtUtils::FakeMaker is now Module::Faker. Schwern suggested that
ExtUtils should no longer be used, and gave excellent reasoning, summed up
here:
http://www.perlfoundation.org/perl5/index.cgi?extutils
So, that's done. There haven't been any changes worth mentioning, yet, in its
docume
# from Matisse Enzer
# on Friday 14 March 2008 12:20:
>and when you see a
>"use" statement, you know what the corresponding package is, and have
> a good clue about the path path of the file you are importing.
Well, a "use" statement literally defines the name of the file (per
`perldoc -f re
I'm discussing some potential refactorings at $work at wanted to give
an articulate explanation of the benefits of having package
declarations match file names, so that:
# file is Foo/bar.pm
package Foo::Bar;
One reason is so that when you see a "package" statement, you know
what the
