> -----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 [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
