Lexical scope and inheritance scope - clarification and motivation.

[rakudrama]

Peter requested that the language issue be discussed in a different bug to Issue #641.

According to the current lookup rules, lexical scope is exhausted before considering inheritance scope.

The following program should print 89:

  int x = 89;

  class Foo {
    int x = 42;
  }

  class Bar extends Foo {
    m() => x;
  }

  main() {
    print(new Bar().m());
  }

Do we have the same answer if we replace 'x' with 'x()' and '=' with '=>' ?

I am not alone in finding that this rule feels strange, so I think the motivation needs to be explained to the Dart community.

On the surface, it seems that collections of classes will become fragile as new global definitions can usurp the lookup path. Design patterns that use implementation inheritance will be particularly susceptible. Our target market, web applications, has a large user-interface component, and user interface libraries often use implementation inheritance to customize the UI - subclassing interaction units like menus, buttons etc. To avoid accidents, programmers will have to make use of defensive 'this.' and 'super.', which will clutter the application code.

The cohesion between the classes in a hierarchy is usually much higher that between a leaf class and the global environment. Programming languages should make the common case convenient ahead of the less common.
Dart appears to put the less common ahead of the common.

Why is Dart's lookup order like this?
What are the advantages?

[rakudrama]

Marked this as blocking #641.

[gbracha]

A future rev of the spec will give an extended rationale. At its root, the issue is capture of lexical scope by superclasses. Lexical scope is under the control of the developer of a library, whereas superclasses are not. Hence, it is not the library scope (Dart has no global scope) that "usurps" the lookup path, but the opposite.

Put another way - class hierarchies within a library have high cohesion, but when relying crossing library boundaries they do not. Assuming they do is a common mistake, repeated in several earlier programming languages.

Warnings about shadowing should probably be refined to warn about these situations - though proper tooling would be enough (e.g., highlight any inherited name that is hidden by the lexical scope).

There are also considerations with respect to future evolution of the language.

Concrete scenarios illustrating these issues will come in due course.

---

Set owner to @gbracha.
Added Accepted label.

[gbracha]

Added this to the M1 milestone.

[gbracha]

Added some discussion and a basic example to section 3.1.

---

Added Done label.