This comment was originally written by zundel@google.com

I did cook up one case where a programmer can be caught off guard and no warnings will be emitted by an errant library upgrade. Assume that a developer is using two third party libraries, libA and libB

libA.dart:
foo() {
  return "libA";
}

libB.dart:
class B {
  foo() {
    return "libB";
  }
}

user code:

import ("libA.dart");
import ("libB.dart");

class myClass extends B {
  String libAFeature() {
    return foo(); // resolves to top level foo() in libA.dart
  }
}

Now, at some point, libA is updated so that foo() is renamed.
libA.dart:

newFoo(int a) {
  return "libA";
}

Now, if you run the usercode libAfeature(), the invocation of foo() now resolves to the superclass method for 'foo()'. Its all well and good to say that libA shouldn't have it renamed its top level method, but that is in a library that the user code doesn't control.

The proposed 'global' qualifier would have provided a way for the library user to protect themselves. Another way the user could have protected themselves from this kind of change is to prefix the library.

I think the cleanest solution to this would be in the context of first class libraries and/or class nesting. In the meantime, we should leave this open until a comprehensive approach presents itself.

Set owner to @gbracha.
Added Accepted label.

Added this to the Later milestone.

This comment was originally written by waprave...@gmail.com

The obvious thing is to search the class hierarchy for the method and if it doesn't exist there then search the top level.

This

void go() {
  print("Hello from Global");
}

class Base
{
  void go() {
    print("Hello from Global.Base");
  }
}

class Test extends Base {
  void readySet()
  {
    go();
  }
}

void main() {
  Test t = new Test();
  
  t.readySet();
}

and this

void go() {
  print("Hello from Global");
}

class Base
{
  void go() {
    print("Hello from Global.Base");
  }
}

class Test extends Base {
  void readySet()
  {
    super.go();
  }
}

void main() {
  Test t = new Test();
  
  t.readySet();
}

should produce the same result.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

This comment was originally written by @seaneagan

Might make sense to use the "as" keyword on "library":

library foo as foo;

import 'package:bar/bar.dart'; // Has a top-level bar.

var baz;

class Bar {
  var bar, baz;

  get bloop => [bar, foo.bar, baz, foo.baz];
  
}

No current plans to add this feature. A top-level scope identifier should not be used defensively, because that would mean writing it everywhere. It should at most be used when necessary.

A partial workaround is (or should be):

import "" as top;

which makes the current library's export scope available.
It does not give access to imported libraries, but those can also be imported with a prefix directly.
It does not give access to private top-level declarations. Those should be entirely under the control of the library author, so they can be renamed without breaking anyone.