I vaguely recall doing something rudimentary that did something kind of
like this. I think I did something where every verb was a Verb::something.pm
module. Then I just wrapped a "use Verb::something;" statement in an
eval("") statement, inside an eval{} block. Simple and dumb, but it worked
good enough that people used the script.
it was a script for internal use only so there werent huge gaping security
holes to the outside world.
-----Original message-----
From: John Redford <eire...@hotmail.com>
To: 'L-boston-pm' <boston-pm@mail.pm.org>
Sent: Tue, Aug 9, 2011 14:18:51 GMT+00:00
Subject: Re: [Boston.pm] module introspection
-----Original Message-----
> From: Tom Metro
> Sent: Monday, August 08, 2011 12:48 PM
> Subject: [Boston.pm] module introspection
> I have a command line utility I am developing that I'd like to be
> extendable with additional "verbs" such that you can do:
>
> command verb ...args...
>
> And I'd like the utility to be able to support new verbs by merely
> having a module added to a designated directory. Thus I'd like my code
> to be able to use some form of introspection to extract the new verbs
> (designated methods) from the modules.
As is often the case, there are swings and roundabouts.
You could take the ksh FPATH approach of mapping one verb to one file --
with the advantage that you only have to load a single file and you know
which one to load based on the verb provided. This also makes it efficient
to check internally or tell a user what verbs exist, as you just need to
enumerate the file names. If you want to display "help" information about
all the verbs at once you have to read all the files, but that's an unusual
case and not something to be optimized for (and if you wanted to, you could
simply cache the data in another file and check its content/timestamps
against the names & stamps of the verb files). In this case, you don't need
to "introspect" -- the loaded file is simply expected to contain the verb
you're looking for -- either by defining it as a named function, or by
putting a function into some existing hash of verb names.
Alternatively, you could require the program to load and evaluate every
verb-defining file, permitting files to define multiple verbs -- a mechanism
that mimics how modules export names would be conventional here. In general,
this would be a worse approach, as you're incurring the worst-case overhead
and loading verbs you aren't using. However, if your program operates as a
long-running, interactive shell, this might be reasonable.
Finally, you could combine the two with the optimization mentioned above --
create a single cache file that combines all the verbs (or perhaps just the
registration data for all the verbs) into a single file, which you load, and
which contains either the full verb definitions or enough information to
efficiently load them when needed.
The first approach is simple, generally efficient and self-evident in its
properties. The second and third are much fancier, but seem excessively
complicated and subtle for the basic problem described.
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
