简体   繁体   中英

Identifier shadows elements in Dart:core

If an identifier is defined in the current dart file, then that identifier shadows elements with the same identifier that are defined in other files included using the import directive. When using such an identifier in the current file, no errors occur, the version from the current file is used.

If some id is defined in file 1 and file 2, but is not defined in the current file, then an error will occur when trying to apply the identifier, which can be eliminated by using import prefixes or show, hide commands.

The logic described above is clear. But when working with the dart:core library, the following error may occur. Let's consider the cause of the error using the print function as an example.

If the print function is not defined in the current file and that function is defined in one of the import files, then the dart:core version of the library will be grayed out. No compilation errors that require an import prefix or the show/hide command will be generated.

The described situation can lead to confusion. The same applies to some other dart:core libraries. There are examples below.

// test2.dart
void print() {
}
// test.dart
import 'test2.dart';

void main() {
  // some useful function from test2.dart
  print2();

  // static error due to inappropriate argument types,
  // not due to collision with print function from dart:core
  print('work is done');
}

This error persists when explicitly including the dart:core file.

In connection with what has been said, there are the following questions.

  1. Will the dart developers read my message, or where do they need to forward it to read it?

  2. Is this really a bug or was it meant to be? I propose to correct it so that the language is more simple and understandable.

I expected that if an identifier in one of the files matches an identifier from the dart:core library, the behavior will be the same as if a simple other package, file.

The rules for name conflicts are special for names coming from platform ( dart: ) libraries.

Normally if you import different declarations with the same name through two different imports, it's a conflict . You get an error if you try to refer to the name, because the compiler cannot figure out which one you mean.

However, if you import different declarations with the same name, and some, but not all, come from dart: libraries, then the declarations from the dart: libraries are ignored, and the non-platform libraries take precedence. (And if there is only one declaration from a non- dart: library, it just works as normal.)

The reason for this exception is that Dart libraries typically come from packages, where you can control which version of the library you get. You won't get new declarations without doing a dart pub update or similar. That means that a new name conflict are only introduced at times where you are actively developing, and you can then handle.

Platform libraries come from the SDK, and your SDK can be updated independently of the packages you are working on. Even if you tested your application thoroughly and locked all your dependencies to specific version that you know will work, it might end up being run on a newer SDK.

Because of that, adding new declarations to the platform libraries was considered more dangerous than adding them to normal packages. To avoid it being practically impossible to add anything to the platform libraries, it was instead decided to not make such new conflicts into errors.

If the platform libraries introduce a new declaration, it should not affect your imports. It won't introduce a new conflict. (It can cause other errors, because no API change in Dart is ever entirely safe, but at least it won't cause import conflicts.)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM