# from Johan Vromans # on Tuesday 11 April 2006 11:48 am: >It could be done this way. There is no real convention for >applications, and the scripts archive is a failure.
Well, I just started on Class::AppDispatch, which is somewhat like App::CLI, but I'm not too keen on naming it App::ClassDispatch, since it is a class that helps with apps and not an app that helps with classes. >The only disadvantage I see is that you get a namespace clash when two >apps share the same name. That happens in bin/ as well though, so I think those clashes are necessary. It's the sort of thing where a module named App::Helper would clash with an app named "helper" that bothers me. I would personally like the App::* namespace to be strictly for application code modules. >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. >And how to use the Test::* framework for apps? I've been experimenting with a require()able pattern lately that is specifically designed to be testable without mucking around in file handles. It is intended to allow the code to easily transition from script to module, but I have not yet had many chances to smoke test (or really Test::*) the idea. I'm sort of guessing at the order here. I think these roughly represent a progression. http://scratchcomputing.com/uc/trunk/code/perl/bin/xar2crs http://scratchcomputing.com/uc/trunk/code/perl/bin/uber http://scratchcomputing.com/svn/misc/trunk/code/perl/bin/cwd_proc http://scratchcomputing.com/svn/misc/trunk/code/perl/bin/rmstr http://scratchcomputing.com/svn/misc/trunk/code/perl/bin/oovc http://scratchcomputing.com/svn/code_utilities/trunk/code/perl/bin/podadz http://scratchcomputing.com/svn/App-YmlDB/trunk/bin/ymldb --Eric -- Issues of control, repair, improvement, cost, or just plain understandability all come down strongly in favor of open source solutions to complex problems of any sort. --Robert G. Brown --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
