[
https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718115#comment-13718115
]
Dag H. Wanvik commented on DERBY-673:
-------------------------------------
Thanks, Knut. Yes, it is intentional, if slightly confusing. isSameNodeKind is
really only a helper for isEquivalent. For SpecialFunctioNode and
TernaryOperatorNode isEquivalent tests on kind directly without a call to
isSameNodeKind (because they have no derived classes). Perhaps it might look
cleaner if we let them define isSameNodeKind also?
ModifyColumnNode is not a ValueNode, so isEquivalent is not present (and hence
no isSameNodeKind is needed either).
There are some cases that use the default in ValueNode, e.g.
BooleanConstantNode, UntypedNullConstantNode, other ConstantNode classes do
have kinds. But I guess I could move it down to ConstantNode for that case. I
still think it's nice to tie all the kind usages together, though, so if not
via a default method in ValueNode, I guess I could make them implement a
NodeKinds interface?
> 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.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
