Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: scripting frameworks - a cursory glance

by krazyk (Beadle)
on Mar 18, 2010 at 14:37 UTC ( #829407=note: print w/ replies, xml ) Need Help??


in reply to scripting frameworks - a cursory glance

I am Glad you like CLI::Framework (I'm the author). Just a couple of things worth mentioning...

Those who are interested can see CLI::Framework design goals and features for a concise list of what is offered by "CLIF." This feature list is, in a nutshell, why I created CLIF instead of using another module intended to assist in building command-line applications.

There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache. Commands are aware of the cache, but they are generally unaware of the application (metacommands are an exception). This is by design to encourage decoupling commands from applications. Commands could conceivably be used and reused independently from applications. Your commands will use $self->cmd_method() to call a command method and usually should not directly call app methods. However, when necessary (as in some of the built-in commands), they'll do so using $self->get_app()->app_method(). Thus, command methods are called via command objects and if a particular command is application-aware, it has a get_app() accessor which returns the app object. See the definition of a Metacommand and the POD for Command::Meta.

Finally, be aware that I'm still standing behind the distribution. It's still relatively young and has some rough edges that I plan to polish. I'm doing this "on the side" and primarily for myself, but if anyone is using it and has any requests or suggestions, let me know. I'd still like to make it a nice solution for everyone's needs!

One additional module to add to your list: App::CLI. Maybe I'm biased, so I'll let you draw your own conclusions.


Comment on Re: scripting frameworks - a cursory glance
Select or Download Code
Re^2: scripting frameworks - a cursory glance
by metaperl (Curate) on Mar 24, 2010 at 15:58 UTC
    There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache.
    Yes, but the cache is a component of the application object. And the command object should access application object components via  $self->app->cache not the current way $self->cache
      You are mistaken. The cache object accessible by $self->cache() (where $self is the Command) is the same cache used by the application (and your suggested $self->app->cache() would, if it were supported, do exactly the same thing -- access the cache shared by both the Application and the Command). Once again, the cache is shared state. It is not a "component" of the Application, but rather an instance variable (a reference to the Cache object) kept in both Application and Command.

      It would make no sense for "application object components" to be accessed via the cache (regardless of the syntax used to access the cache). The cache stores whatever a user wants to share (like a logging or a database object), not internal CLI::Framework data.

      If you're reading the code, then yes, the Cache class happens to be implemented inside the Application module (mainly because the existing Cache class is trivially simple and may later be replaced by a more powerful caching system like CHI; I decided it is unworthy of its own module at this stage). But that doesn't make it a "component" of the Application class.

        It would make no sense for "application object components" to be accessed via the cache (regardless of the syntax used to access the cache).
        You're right it wouldnt. That was a mis-wording. But: the command object should access application object resources via $self->app->$resource not the current way $self->$resource where $resource might be a slot in the application object or a slot in the command object.

        And: the cache is a resource that the command requires the application to implement and provide. You mentioned uploading Commands to CPAN separately. What sort of interface should a command have with the application? Should the application boldly and indiscriminately put any numbers of slots in the command? Or should there be one well-defined interface via one method between command and object, namely $self->app

        This code (in CLI::Framework::Application):

        # Share session data with command... # (init() method may have populated global session data in cache # for use by all commands) $command->set_cache( $app->cache );
        Should raise a red flag, because over time as various commands require various application-level resources, you are going to have to manually keep coding the wedding between application and object here with additional slot injection instead of one well-defined interface via one method between command and object, namely $self->app

        n-fold fanout

        Just think of what you're doing... let's just say there are 3, as you put it, "instance variables kept in both Application and Command. ", cache1, db_handle, interprocess_communication. Now, you have 4 commands. With your approach, you install all 3 of these accessors in all 4 commands, for a total of 12 accessors for sharing data between application and command.

        With my approach, only the app accessor is shared between application and command, for a total of 4 accessors. As the number of shared resources grow, your "accessor bloat" grows linearly. My "bloat" is constant at 1.


        Furthermore, in a pure OO language like Smalltalk, you wouldnt be able to implement the relation between Application and Command that you have.

        Finally, what happens when each command needs a cache in addition to the application-wide cache? It can no longer have a local cache via $self->cache because the Application decided for the Command what names it would use within its own object.


Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://829407]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (14)
As of 2014-10-21 19:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (107 votes), past polls