db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-673) Get rid of the NodeFactory
Date Thu, 18 Jul 2013 13:50:55 GMT

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

Dag H. Wanvik commented on DERBY-673:

Uploading two alternate patches, derby-673-nuke-ctypes-without-enum and derby-673-nuke-ctypes-enum.
Both remove 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.

The one patch implements "kind" using enums, the other using static final ints. I first implemented
with enums, but it turns out it adds a bit more weight than one would like. Sizes of the insane
jars compiled using java 1.8 EA b94:

 derby.jar [before the patches]:  3017406 
 derby.jar [iwith enum]:                3024918 
 derby.jar [with static ints]:          3007835

so I guess we'd better use the leaner version (it improves on footprint rather than increases
it). Comments appreciated.
Regressions ran OK.

> 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.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