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

[Matt S Trout]

This is the most coherent message to show the lines along which we were
thinking (hdp is confound on #dbix-class).

Those of you who don't have context for this, poke the list archives.

Those of you who do, please bear in mind when responding what anything
involving the creation of assloads of objects will be laughed at and/or
ignored since the intention is SQL::Abstract-level performance.

On Thu, Jun 28, 2007 at 09:38:58PM -0400, Hans Dieter Pearcey wrote:
> Here are some very preliminary thoughts.  Like I said, I'm fried from YAPC, so
> who knows how useful this will be.
> 
> * 2-pass system:
>   * DWIM AST -> explicit AST
>   * explicit AST -> backend
> * lol-only AST means no key collisions, complete control over ordering
> 
> >>> { foo => 1 }
> 
> [ -statement,
>   [ -key => 'foo' ],
>   [ -op => 'is' ],
>   [ -value => 1,
> ]

  [ -op, 'is', [ -ident, 'foo' ], [ -value, \1 ] ]

(values should always be a ref so we can change 'em easily later)
 
> >>> { foo => 1, bar => { '!=' => 2 } }
> 
> [ -cond => 'and',
>   [ -statement, ... ]
>   [ -statement, 
>     [ -key => 'bar' ],
>     [ -op => 'is_not' ],
>     [ -value => 2 ],
>   ],
> ]

  [ -op, 'and', [ -op, 'is', ... ], [ -op, '!is', ... ] ]

(I think the ! will be easier to parse)

> alternately, if we don't want 'not' ops,
> 
> [ -cond => 'and',
>   [ -statement, ... ]
>   [ -cond => 'not',
>     [ -statement, 
>       [ -key => 'bar' ],
>       [ -op => 'is' ],
>       [ -value => 2 ],
>     ],
>   ],
> ]
> >>> [ foo => 1, baz => [ 3, 4 ] ]
> 
> [ -cond => 'or',
>   [ -statement, ... ]
>   [ -cond => 'or',
>     [ -statement,
>       [ -key => 'baz' ],
>       [ -op => 'is' ],
>       [ -value => 3 ],
>     ],
>     [ -statement,
>       [ -key => 'baz' ],
>       [ -op => 'is' ],
>       [ -value => 4 ],
>     ],
>   ],
> ]
> 
> >>> [ foo => 1, baz => { -in => [ 3, 4 ] } ]
> 
> [ -cond => 'or',
>   [ -statement, ... ]
>   [ -cond => 'or',
>     [ -statement,
>       [ -key => 'baz' ],
>       [ -op => 'in' ],
>       [ -value => [ 3, 4 ] ],
>     ],
>   ],
> ]

I think the value should be an explicit list, so

[ -op, 'in', [ -ident ... ],
  [ -list,
    [ -value, \3 ],
    [ -value, \4 ]
  ]
]
 
> special things: -statement, -cond, -key, -op, -value
> 
> a statement is a key, an op, and a value.

No, because the RHS could be an identifier.

Ops - maybe we should explicitly do -binop but really we should always
given them arity. maybe -op1, -op2, -op_list ?

> notes:
> * I don't really like '-statement'.  is there a better name?

I don't see a need for it. -op, -list, -ident, -value, -func should be
enough, no?

> * Is the leading '-' actually useful for anything?  visual marking?

Lack of quoting requirement.

> * do statements need to be lols, or could they be hashrefs? might a statement
>   ever have two keys? I can't imagine how -- I would expect it to decompose into
>   two statements.

Sod hashrefs, they only lead to annoyance.

> * what ops do we need? is, regexp... isa? like could be sugar for regexp.
> * where does per-backend stuff go?

Its own class, delegated to as appropriate, I think.

>   do we need -op => { sql => 'in', ldap => ... } ?
> * where is extensibility most important and how do we add it?
>   * new op types
>   * anywhere else?

I think we'll find that out by implementing.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/             http://www.shadowcatsystems.co.uk/ 

----- End forwarded message -----

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/             http://www.shadowcatsystems.co.uk/