Harmonisation of field vs non-field (method vs. non-method) access (calls)

[oxisto]

This issue is a collection of things that are currently wrong with our call expression

• In the frontend we cannot decide whether something is a member call or just a qualified call to a function of an import, e.g. foo.bar() is either a MemberCallExpression with base foo or a CallExpression to foo.bar (of package foo)
• In C++ and Java, (and other languages) we can leave out this. So if you are calling foo() inside a method, it could either be a call expression to a global function (this is only possible in C++) or a method foo. In the frontend, we can only create a CallExpression, but in the end we would actually have a MemberCallExpression with a base to the receiver. But we cannot create that in the frontend unless we do some resolving there.

After a short discussion, we came to the following conclusion:

• We leave the member expression / member call expression system like it is, but we make sure that the final graph only contains member (call) expression that really are field accesses / method calls. This also means that calls that have an implicit receiver will need to be converted
• Frontends should not decide whether something is a member call expression or not, if they cannot do that (see python). In this case, they will probably return a "wrong" node after translation and a pass (most likely the symbol resolver) will correct it
• A pass (most likely the symbol resolver) will also correct call expressions that are really member call expressions (e.g., with implicit this)

Some Examples

The C++ expression a::b.c should result in a MemberExpression of c with a base Reference of a::b. The same applies for a python expression a.b.c, if a or a.b is an import.

The python and C++ expression a.b.c should result in two nested MemberExpression nodes (b with base a and c with base a.b), if a is NOT an import, i.e., a variable.

[oxisto]

Updated the description with our discussion.