Is this a reasonable use of plugin extensions?

Submitted by Stephen Crawley on Sat, 03/08/2008 - 03:37.

I'm working on a bunch of new classes to replace the way that a command defines its command-line syntax. One of the key points of this is that the command line syntax should be specified independently of the command class. (All the command needs to do is create and supply a "bundle" of Argument objects which say what arguments it expects, and whether they are mandatory/optional, single/repeated.)

In order to make this work, I need to provide a way to express concrete command syntaxes in a separate text file. Naturally, I thought I'd use XML and put them into plugin descriptor file as a new extension point. From what I can tell, this will result in Extension objects containing tree of ConfigurationElement instances. I can then transform these into an in-memory representation of syntax graphs suitable for the command line parser.

Is my understanding of extension points, etc correct?

More important, do people think this is a reasonable use of the plugin extension mechanism? Are there better alternatives?

‹ NestedVM -> Run C/C++ apps natively on JNode Kernel debugger ›

Command syntax in XML

Submitted by lsantha on Sun, 03/09/2008 - 15:44.

can be useful, especially for providing JNode shell speciffic syntax for external command line tools. But I would prefer to see it as an extension to the current approach. I think it's OK to specify the syntax for our commands in the source itself in some way.

I wonder what syntax features will that bunch of new classes support... As a minimum it would be nice to supoprt what the current system suports or intended to support but without the bugs.

External syntax has advantages

Submitted by Stephen Crawley on Sun, 03/09/2008 - 23:20.

There are a number of reasons I'm leaning towards (purely) external specification for command syntax:

  • It is interesting.
  • It allows users to customize command syntaxes. (It would be the JNode equivalent to UNIX aliases ... without many of the drawbacks.)
  • It allows a command to use different "styles" depending on the command interpreter. In some cases this essential; e.g. the example of the "rename" command where (it has been suggested) we need different command-specific filename expansion behavior depending on the interpreter.
  • It allows us to enrich the meta-syntax independent of the command source.

That having been said, the Syntax (and MuSyntax) classes are designed so that it is easy to specify a syntax by constructing objects. A very small API change would allow a Command to construct its own syntax this way.

Syntactic constructs ...

Submitted by Stephen Crawley on Sun, 03/09/2008 - 22:08.

The new system will support the equivalent of all existing Argument classes and a richer set of Syntax classes; e.g. syntactic constructs for alternation, repetition, sequences, powersets, arguments, symbols, options (with short and long form names) and optionsets. Custom Argument classes can be added by any application. Custom Syntax classes may also be possible, though they present some difficulties.

My implementation approach is to have the Syntax classes emit a lower-level micro-syntax (BNF like). Parsing is done against the micro syntax by a parser that does full backtracking, including "undoing" Argument bindings when a subtree of the parse fails.

BTW, would it be possible to create an SVN branch for this stuff? That way, interested folks can see it and provide feedback that will help me refine it.