[Dbix-class] SQLA refactor: proposal

[Darren Duncan]

At 7:14 PM +0000 11/25/07, Matt S Trout wrote:
>On Tue, Nov 20, 2007 at 08:14:35PM +0000, Matt S Trout wrote:
>  > So I think the first stage is to create an SQL::Abstract::Parser that
>>  parses SQLA syntax into MuldisD (+extra sqla. definitions) and an
>>  SQL::Abstract::Producer::SQL that converts from MuldisD to SQL, and then
>>  make core SQL::Abstract use that and pass all tests.
>
>Since people appear not to be paying attention, let me clarify a little.
>
>(1) I am proposing we use the *MuldisD* *specification*
>
>(2) Specifically, I am proposing we use the
>
>http://search.cpan.org/~duncand/Language-MuldisD-0.12.0/lib/Language/MuldisD/PerlHosted.pod
>
>specification as an internal AST - i.e. a pre-worked-out set of perl data
>structures to use as the explicit AST that I failed to get a design discussion
>going about months ago. We now have a pre-built one that a smart man has
>spent a lot of time designing, and the smart man is on this list and happy to
>take feedback.
>
>(3) This AST would then be transformed to SQL by various backends, for e.g.
>SQL::Abstract::Producer::SQL which would be a generic backend, then that
>can be subclassed to handle db-specific stuff.
>
>(4) While dduncan plans a complete implementation of MuldisD as part of
>Muldis::DB, the reason I didn't mention this is because no part of this
>proposal involves using it. Anybody who assumed that, please note what the
>first three letters of 'assume' are and try again.

For the record, this is also what I understood.  That you were going 
to use my Muldis D language spec as a jumping off point to redesign 
the internal AST and/or API of the SQL::Abstract framework, and that 
this would otherwise be an independent project from my own 
implementation.  This proposal also helps justify my having made my 
language spec clearly separated from my implementations of it.  And I 
want to help the project to succeed. -- Darren Duncan