db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-673) Get rid of the NodeFactory
Date Thu, 25 Jul 2013 07:13:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719318#comment-13719318

ASF subversion and git services commented on DERBY-673:

Commit 1506827 from [~dagw] in branch 'code/trunk'
[ https://svn.apache.org/r1506827 ]

DERBY-673: Get rid of the NodeFactory

Patch derby-673-nuke-ctypes-without-enum-3.

This patch removes the usage of the global nodeType integer (see
QueryTreeNode) defined by C_NodeType.java. After the removal of the
node factory, this global quantity whose use mimicked "instanceof" can
be discarded, mostly. For some node which represent several logical
node types, e.g. BinaryArithmeticOperatorNode which can represent for
example both + and minus, a new quantity, "kind" is introduced to
differentiate between the logical types of nodes.

We introduce a default method ValueNode#isSameNodeKind which the
classes that implement several kinds need to override to add the extra
kind check. This is then called from the isEquivalent overrides as

JavaDoc for isSameNodeKind:

 * Some node classes represent several logical node types (to reduce
 * footprint), which we call kinds.
 * This means that implementations of {@link #isEquivalent()}
 * cannot always just use instanceof to check if the other node
 * represents the same kind. Hence this method needs to be
 * implemented by all node classes that represent several kinds.
 * It is only called from implementations of isEquivalent.
 * @param other The other value node whose kind we want to compare with.
 * @return true if this and o represent the same
 *         logical node type, i.e. kind.
> Get rid of the NodeFactory
> --------------------------
>                 Key: DERBY-673
>                 URL: https://issues.apache.org/jira/browse/DERBY-673
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Rick Hillegas
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_11
>         Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status,
derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, derby-673-more-typesafe-6.diff,
derby-673-more-typesafe-6.status, derby-673-nuke-ctypes-enum.diff, derby-673-nuke-ctypes-enum.stat,
derby-673-nuke-ctypes-without-enum-2.diff, derby-673-nuke-ctypes-without-enum-2.status, derby-673-nuke-ctypes-without-enum-3.diff,
derby-673-nuke-ctypes-without-enum-3.status, derby-673-nuke-ctypes-without-enum.diff, derby-673-nuke-ctypes-without-enum.status,
derby-673-typesafe-lists-1.diff, derby-673-typesafe-lists-1.status, derby-673-typesafe-lists-2.diff.gz,
derby-673-typesafe-lists-2.status, nodefactory-31.status, nodefactory-31.zip
> 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message