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
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
