db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-673) Get rid of the NodeFactory
Date Mon, 28 Nov 2005 20:31:38 GMT
    [ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358703 ] 

Rick Hillegas commented on DERBY-673:

This change should not preclude and I expect it would facilitate reorganizations of the type
hierarchy for nodes in the abstract syntax tree. Having said that, I don't think I understand
the motivation for making some nodes not descend from QueryTreeNode. QueryTreeNode is supposed
to be the ancestor of all abstract syntax tree nodes. This is a useful abstraction because
it regularizes compiler code. It removes a lot of special case logic from the handling of
the compilation steps defined by QueryTreeNode: bind(), optimize(), and generate(). In addition,
it forces an engineer, when adding a new AST node, to account for these steps. I can see some
methods in QueryTreeNode which probably belong in its descendants. However, I think QueryTreeNode
basically makes a lot of sense and the code would be a lot uglier without this abstraction.

> Get rid of the NodeFactory
> --------------------------
>          Key: DERBY-673
>          URL: http://issues.apache.org/jira/browse/DERBY-673
>      Project: Derby
>         Type: New Feature
>     Reporter: Rick Hillegas

> This piece of code once had a purpose in life. It was one of the double-joints which
allowed cloudscape to ship with and without compiler support for the synchronization language.
Synchronization has been removed. If we want to plug in optional language components, I think
there are better ways to do this.
> The NodeFactory turned into a big, sprawling piece of code. At some point this code was
slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed
overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce
strongly typed node constructors which the parser can call directly. This will make node generation
easier to read and less brittle and it will get rid of the now useless NodeFactory class.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message