[ http://issues.apache.org/jira/browse/DERBY-673?page=comments#action_12358697 ]
Daniel John Debrunner commented on DERBY-673: --------------------------------------------- Would this change allow some rationalization of the type hierachy for nodes? Every "node" is a sub-class of QueryTreeNode, but it seems to me that several nodes are forced into the hierachy through the use of the NodeFactory. Any "node" that is really a data element would seem to fall into this. E.g. TableName, TableElementNode and its sub-classes. It's possible those nodes do not need to be sub-classes of QueryTreeNode. > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
