The future of naming

[oxisto]

As discussed in the last developers meeting, we have a major problem about consistent naming of things and we need to tackle this before redesigning anything close to symbol resolving.

The current situation

Everyone Node has a name property. This is set mostly to the local name of a declaration or expression, such as printf. However, there are two special cases to naming:

• A RecordDeclaration expects to have its fully qualified name (FQN) set to the name property, otherwise certain things won't resolve.
• A CallExpression has an additional fqn field that expects the FQN of the call target, such as MyClass::method. However, this only seems to be used for static call resolutions? Not exactly sure
• I have seen MethodDeclaration nodes that "live" outside of a class be named MyClass::method, although I cannot 100 % confirm this in the code right now.

We have a major problem in properly resolving scoped calls because for some of the nodes, we do not know its FQN and for some we just seem to ignore it.

There are also two functions in the ScopeManager that try to retrieve the current "namespace": currentNamePrefix and currentNamePrefixWithDelimiter although I am a bit lost why there are two functions, one of which just seems to append the current namespace delimiter (such as ::). I would assume that this works correctly.

Possible Solutions

Option A: Name class

The first option would be to keep using one name field (and removing all others), but instead of having this as String, it would be a special Name class which does the heavy lifting. A Name would then probably have properties like a simpleName and a parent to model something like Name("method", "MyClass", "::").

Advantages

Cleaner and we can "enforce" proper hierarchy in names.

Drawbacks

• We cannot simply assign / compare name strings anymore, we always need to instantiate a Name class such as node.name = Name("myName"), even though we only want a simple name without any namespace. Maybe there is some Kotlin magic? @maximilian-galanis
• We somehow need to "inject" the namespace delimiter into the name, as this might be different per language frontend. So either we need a reference to the frontend in the name or store the delimiter as well. Maybe we can work around this with an extension function in the LanguageFrontend that does that for us.

(to be finished later)

Option B: Two fields name and fqn

Alternatively, we introduce two fields. name which is always the local name and fqn which is the (optional) FQN of the node.

Advantages

Leaner, can use String for both.

Disadvantages

We once again rely on the developer to do things right, e.g., having the right delimiter and we cannot enforce proper hierarchy of names because it is just a string.

Option C: Maybe both-ish?

Third option could be to keep name as a string and have a separate field (maybe fqn maybe fullName) that uses the Name class. But we still then would need to keep them in sync. But this could maybe be done with Kotlin setters/getters, where name is basically just a virtual property and fullName is the backing field.

[maximilian-galanis]

Regarding the drawbacks of Option A:
Because Kotlin property setters cannot be overloaded, we can't have everything at once. But by combining a delegated property with a normal property we can come pretty close:

abstract class Name(var localName: String, var parent: Name?, private val delimiter: String) {
    override fun toString() = localName + (if (parent != null) delimiter + parent.toString() else "")
    override fun equals(other: Any?): Boolean = TODO("Add checks for both Name objects and Strings")
    override fun hashCode() = toString().hashCode()
    operator fun getValue(node: Node, property: KProperty<*>) = toString()
    operator fun setValue(node: Node, property: KProperty<*>, s: String) {
        parent = null
        localName = s
        // maybe analyze [s] to generate parents too
    }
}
// or use a language frontend specific factory method to get Name objects with the correct delimiter
class JavaName(localName: String, parent: Name? = null) : Name(localName, parent, ".")

abstract class Node(val nameObject: Name) {
    var name: String by nameObject  // access to name is delegated to getValue and setValue of nameObject
}

class JavaNode(nameObject: Name) : Node(nameObject)

This would allow the following syntax:

val node = JavaNode(JavaName("myName"))
node.name == "myName"  // returns true
node.nameObject.localName  = "myOtherName"
node.name == "myOtherName"  // returns true
node.nameObject == JavaName("myOtherName")  // also returns true
node.nameObject == "myOtherName" // also returns true

With some hacks we can get even closer at the cost of loosing static type checking: https://stackoverflow.com/a/46371105

[oxisto]

Regarding the drawbacks of Option A: Because Kotlin property setters cannot be overloaded, we can't have everything at once. But by combining a delegated property with a normal property we can come pretty close:

abstract class Name(var localName: String, var parent: Name?, private val delimiter: String) {
    override fun toString() = localName + (if (parent != null) delimiter + parent.toString() else "")
    override fun equals(other: Any?): Boolean = TODO("Add checks for both Name objects and Strings")
    override fun hashCode() = toString().hashCode()
    operator fun getValue(node: Node, property: KProperty<*>) = toString()
    operator fun setValue(node: Node, property: KProperty<*>, s: String) {
        parent = null
        localName = s
        // maybe analyze [s] to generate parents too
    }
}
// or use a language frontend specific factory method to get Name objects with the correct delimiter
class JavaName(localName: String, parent: Name? = null) : Name(localName, parent, ".")

abstract class Node(val nameObject: Name) {
    var name: String by nameObject  // access to name is delegated to getValue and setValue of nameObject
}

class JavaNode(nameObject: Name) : Node(nameObject)

This would allow the following syntax:

val node = JavaNode(JavaName("myName"))
node.name == "myName"  // returns true
node.nameObject.localName  = "myOtherName"
node.name == "myOtherName"  // returns true
node.nameObject == JavaName("myOtherName")  // also returns true
node.nameObject == "myOtherName" // also returns true

With some hacks we can get even closer at the cost of loosing static type checking: https://stackoverflow.com/a/46371105

That sounds pretty close to the ideas that I had in Option C. There is just one more problem challenge: It is tricky to get the current "parent" and delimiter. We can pretty much only do that in the parsing (e.g. in a Handler when we have access to the language frontend (in the property lang), but we do not have access to it in the setter (or in the Node itself). We could work around that by somehow storing the language frontend of each node, but this also adds some additional overhead.

[maximilian-galanis]

Regarding the drawbacks of Option A: Because Kotlin property setters cannot be overloaded, we can't have everything at once. But by combining a delegated property with a normal property we can come pretty close:

abstract class Name(var localName: String, var parent: Name?, private val delimiter: String) {
    override fun toString() = localName + (if (parent != null) delimiter + parent.toString() else "")
    override fun equals(other: Any?): Boolean = TODO("Add checks for both Name objects and Strings")
    override fun hashCode() = toString().hashCode()
    operator fun getValue(node: Node, property: KProperty<*>) = toString()
    operator fun setValue(node: Node, property: KProperty<*>, s: String) {
        parent = null
        localName = s
        // maybe analyze [s] to generate parents too
    }
}
// or use a language frontend specific factory method to get Name objects with the correct delimiter
class JavaName(localName: String, parent: Name? = null) : Name(localName, parent, ".")

abstract class Node(val nameObject: Name) {
    var name: String by nameObject  // access to name is delegated to getValue and setValue of nameObject
}

class JavaNode(nameObject: Name) : Node(nameObject)

This would allow the following syntax:

val node = JavaNode(JavaName("myName"))
node.name == "myName"  // returns true
node.nameObject.localName  = "myOtherName"
node.name == "myOtherName"  // returns true
node.nameObject == JavaName("myOtherName")  // also returns true
node.nameObject == "myOtherName" // also returns true

With some hacks we can get even closer at the cost of loosing static type checking: https://stackoverflow.com/a/46371105

That sounds pretty close to the ideas that I had in Option C. There is just one more problem challenge: It is tricky to get the current "parent" and delimiter. We can pretty much only do that in the parsing (e.g. in a Handler when we have access to the language frontend (in the property lang), but we do not have access to it in the setter (or in the Node itself). We could work around that by somehow storing the language frontend of each node, but this also adds some additional overhead.

Perhaps I don't understand the full scope of the issue, but as far as I understand it, the Handler, which has access to its LanguageFrontend, creates the Nodes. So by passing a language specific Name object (e.g. JavaName) as the name argument to a Node instead of a String we have all the information we need. The JavaName object contains the delimiter and the "parent" information.
The Node can then use its nameObject property (which is the language specific Name object passed to this Node by the handler) to access/edit the used delimiter as well as the "parent" information.

And by using the language specific nameObject property as a delegate, we can access both, the delimiter as well as the "parent" information in the setter/getter of the var name: String by nameObject property too.

[oxisto]

For starters we probably do not want language specific name classes. However, we could hide setting the delimiter from the language frontend in the NodeBuilder. We currently anyway only use the node builder for new nodes such as newFunctionDeclaration(name, lang=lang). This could then use the information from the language frontend.

[peckto]

From a software engineering perspective, having a Name class looks for me like the cleanest solution.
When thinking about the neo4j database, how can we "store" the name object there?
Do we need some custom serializer for that?
I assume, we need to store the Name class attributes as node properties?

[oxisto]

We need a custom serializer that translates this into a fully qualified name string (and back to a Name). This is actually why this PR (#931) is failing.