Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symbols representing library names starting with _ cannot be created. #16445

Closed
lrhn opened this issue Jan 31, 2014 · 5 comments
Closed

Symbols representing library names starting with _ cannot be created. #16445

lrhn opened this issue Jan 31, 2014 · 5 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-not-planned Closed as we don't intend to take action on the reported issue library-mirrors type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@lrhn
Copy link
Member

lrhn commented Jan 31, 2014

Symbols represent source names.
The "dotted identifers" symbols appear to represent library names, so #a.b.c is the symbol corresponding to the library declaration library a.b.c;.
(They can also be used to represent constructor names, like #Foo.bar, but I believe that use is being phased out, and the (simple) name of the constructor will only be #bar).

The problem is that a library name may start with _, but it is not at all obvious what that means wrt. privacy.

If it means the name is "private" (i.e., not equal to the same sequence of characters in another library), then you can't give a warning if the library source is imported more than once (it will be different libraries), or if two libraries have the name _a, and they may even import the same part file. That sounds like unintended consequences that might be abused.

On the other hand, if _a is not considered private as a library name, then the symbol #_a will not match it, because the symbol is private.
Also, there is no way to create a symbol for that library - all attempts to do so will create a private symbol instead. And we probably don't want to have _a as a non-private symbol too, that will be too confusing.

My suggestion is to disallow library names starting with _.
That may be a breaking change.
Alternatively, let them exist, but then we need to know what the library mirror of the library will return as the name,.

@rmacnak-google
Copy link
Contributor

What falls out in the current implementation -- i.e., from consistently applying privacy to identifiers -- is that the library's name is private wrt itself. So,

library _foo;
import 'dart:mirrors';
class C {}
main() {
  var thisLibrary = reflectClass(C).owner;
  var a = #_foo;
  var b = thisLibrary.simpleName;
  var c = MirrorSystem.getSymbol('_foo', thisLibrary);
  print(a == b); // true
  print(b == c); // true
}

Banning private library names seems more tractable than declaring some identifiers starting with underscore to not be private. This might be small enough for TC52 to address.

@peter-ahe-google
Copy link
Contributor

It seems to me that the most consistent thing is that all names in a compilation unit are mangled the same way.

The whole foundation for our privacy mechanism was that it could be implemented by mangling during lexical analysis.


Set owner to @gbracha.
Removed Area-Language label.

@lrhn
Copy link
Member Author

lrhn commented Feb 13, 2014

Actually, I just found this in the specification:
"Privacy applies only to declarations within a library, not to library declarations themselves."
(which probably also applies to "part of" declarations), so I guess library names should not be mangled.

That means that you can have:
  library _foo; // Not private.
and no good way to create a symbol for the name.

@lrhn
Copy link
Member Author

lrhn commented Feb 13, 2014

It would perhaps be better if the mirror system did not use symbols for library names at all, and just used strings instead.

@johnniwinther
Copy link
Member

Also, the use of Symbol for qualified names introduces similar problems.

@lrhn lrhn added Type-Defect library-mirrors area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. labels Feb 13, 2014
@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed priority-unassigned labels Feb 29, 2016
@a-siva a-siva added closed-as-intended Closed as the reported issue is expected behavior closed-not-planned Closed as we don't intend to take action on the reported issue and removed closed-as-intended Closed as the reported issue is expected behavior labels Aug 5, 2022
@a-siva a-siva closed this as completed Aug 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-not-planned Closed as we don't intend to take action on the reported issue library-mirrors type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

7 participants