On Fri, Jan 24, 2020 at 6:58 PM tyson andre <tysonandre...@hotmail.com> wrote:
> > I like the idea of using a meaningful value here, but think that this > > should be using a string, i.e. > declare(function_and_const_lookup='global') > > rather than declare(function_and_const_lookup=global). Currently > declare() > > syntax uses a normal constant expression on the right hand side of the =, > > and I don't see a strong reason why we should deviate from that for this > > feature. An existing declare using a string is declare(encoding='UTF-8'). > > Whether it's quoted is a low priority to me - I went with the unquoted > implementation > because it might be something repeated in every file of a project, > and it'd be slightly more convenient to avoid quotes and use keywords if > there were > many more settings with different values (=on, =off, =warning, etc) in the > future. > A difference is that it makes sense to quote encodings such as UTF-8 > because of the '-', > but not as much to quote keywords without special characters. > Saving two characters per file doesn't seem like a great motivation to add additional special cases to core language syntax. Right now, declare just types "identifier = expr", while with this change it's going to be "identifier = (expr | a | few | extra | keywords)". > > One option that I haven't seem much discussion on is the opposite: Always only look in the global namespace. Any unimported unqualified usages will be treated as fully qualified names. > > This would match the proposed semantics for functions/consts and change the resolution rules for classes. > > I think this would have relatively little impact on how code is written, as classes already tend to make extensive use of cross-namespace references and the import is usually IDE managed. > > It's fairly common for NS\SubNS\ClassName to mention other classes from NS\SubNS\OtherClassName right now, > (more commonly than use Exception, use Throwable, etc in some cases), Out of interest, I checked how the symbol reference distribution in open-source projects look like. These numbers are for unique class name references inside namespaces: Global: int(88398) Same namespace: int(83790) Other namespace: int(315455) So, most references are to classes outside the current namespace. The number of references to global classes and classes in the same namespace is actually pretty similar, there are 5% more global references. >From that perspective, changing the name resolution rules to always look for the global symbol if unimported would actually slightly reduce the number of necessary "use" statements. > and changing that default would require changing a lot of third party code. > A separate option such as `declare(lookup_classes=global)` would allow migrating to that, > but would confuse developers switching between codebases using different settings of lookup_classes, > and introduce similar confusion about the rare case of multiple classes in one file. If we were to make such a change (hypothetically), the way I would view it is "use new name resolution rules" or not, rather than a collection of fine-grained options. Notably Rust made a major change to how symbols are resolved in the 2018 edition, so such things aren't inconceivable, especially with the right tooling. Nikita
