Eric Wilhelm <[EMAIL PROTECTED]> writes:
> That happens in bin/ as well though, so I think those clashes are
> necessary.
Yes, but they're relatively harmless. If App::FooBar and App:BarBlech
both prove an app "superapp", then I can choose which one to install.
Okay, I cannot install both apps simultaneously.
But App::SuperApp and App::SuperApp will confuse the CPAN indexer (and
the users as well).
> I would personally like the App::* namespace to be strictly for
> application code modules.
We can turn this into a convention from now on.
>>Another thing to consider is some additional guidelines (conventions)
>>and support for apps. For example, "App::FooBar" would correspond with
>>the application "foobar". But what would the module App::FooBar be?
>>Should the app be a standalone module (e.g., running "foobar" would be
>>the same as "perl -MApp::FooBar")?
>
> That's really a design choice, and I suppose it depends somewhat on how
> many programs are in the application and how you want to structure it.
A related issue is whether the modules of an app are suited for
general reuse. For example, I have an app "foo" that has several
modules in the "Foo" namespace. These modules are dedicated for this
app and hence it is not useful to publish them as individual modules
> I've been experimenting with a require()able pattern lately that is
> specifically designed to be testable without mucking around in file
> handles.
I've been doing so several times. But every time I come up with a more
or less different solution, indicating that the previous solution was
not really satisfying.
An easy start would be to stick to something like:
"foo" app:
#!/usr/bin/perl
use strict;
use warnings;
use App::Foo;
App::Foo::->run();
(Although I do like your
if ($0 eq __FILE__) { App::Foo::->run(); }
approach.)
-- Johan
