mkremins
commented
10 years ago Commit 41d710553c96fbab3ee8de7b6340951c5166b4a1 makes a large step in this direction by removing the flense.parse namespace and replacing it with a flense.model namespace in which naming conventions are more uniform.
There's a number of recurring names in the code that can be used to mean different things in different contexts; there also exist situations in which multiple different names are used to refer to the exact same thing. Examples include:
formcan refer to either a raw Clojure form (i.e. arbitrary EDN data) or a parse-tree node representing a Clojure form (i.e. a map with a keyword:typeand possibly a vector of:children).sexpis used in a few places as a synonym for the latter meaning ofform.treeis used in the names of some conversion functions (e.g.tree->str,form->tree) to refer to parse-tree nodes unambiguously in the presence of code that usesformto mean arbitrary EDN data.nodeis sometimes used to mean the same thing astree. This is most common in the names of predicate functions testing for particular kinds of node (e.g.placeholder-node?,coll-node?) and seems to originate in the use ofz/nodeto retrieve parse-tree nodes from zippers.atomhas started to crop up in newer code as referring to a parse-tree node representing an atomic form, and thus lacking a:childrenvector.tokenin older code (e.g. theparse-tokenfunction) means the same thing asatomtoday. In newer code, it refers instead to anything that can be rendered into the DOM as part of a line.string, others asstr.Most of the particularly egregious examples of inconsistency occur in the
flense.parsenamespace, which has become sort of a grab-bag of largely unrelated application-specific helper functions. Resolving all the naming conflicts listed above may well involve major refactoring, potentially up to and including complete breakup and removal, of this namespace.