[Dbix-class] abstract syntax (extract from a conversation)

Darren Duncan darren at DarrenDuncan.net
Tue Jul 24 07:01:05 GMT 2007


All,

Another thing we should do with the AST is, assume that the spec will 
evolve over time, and give signficant versions of the spec version 
numbers, which are then specified by users within their AoA... 
constructs.

This is analagous to how, eg, XML documents are often tagged at the 
top with a reference to a specific schema version.  Or Perl programs 
say eg "use Dog 2.9;", though the XML example is probably way more 
applicable.

So if a legacy application is writing with an older AST version, and 
meanwhile a library they want to use prefers a newer version, the 
library can deal gracefully when the application passes an AST 
claiming the older spec.  The library can either fail in a helpful 
way saying "AST version is in an out of date" rather than "badly 
formatted AST", or the library can use knowledge of older ASTs, or a 
third party converter, to know how to handle the other versions.

I suggest that the version can be specified as the root node of the 
given AST, for example:

   [-db_ast, '0.4.2', [... what you'd otherwise have as root ...]]

Or that could be expanded slightly, as perl the current Perl 6 
package naming scheme, by adding an authority (to deal with forks or 
alternatives et al) such as:

   [-db_ast, '0.4.2', 'cpan:JRANDOM', [... payload ...]]

For context, everyone should read this:

   http://perlcabal.org/syn/S11.html#Versioning

Assuming we at least think this name/version/authority root node 
thing through well, then the last, otherwise-root node, argument can 
be arbitrarily different over time.

Something functionally similar to this, I must give my highest recommendation.

-- Darren Duncan



More information about the Dbix-class mailing list