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

Improve the support for managing name spaces locally #266

Open
eernstg opened this issue Mar 13, 2019 · 0 comments
Open

Improve the support for managing name spaces locally #266

eernstg opened this issue Mar 13, 2019 · 0 comments
Labels
request Requests to resolve a particular developer problem

Comments

@eernstg
Copy link
Member

eernstg commented Mar 13, 2019

Name space pollution can be a problem: If a library is very large and/or many non-prefixed imports bring a large number of names into scope, it's easy to get into a situation where a name is misinterpreted by a reader of the code, or where a seemingly benign change (adding one more import) creates a name clash, which may require a non-trivial amount of refactoring before things are working again.

Dart allows developers to manage name spaces in certain ways, in particular by using prefixed imports, and by using show and hide in imports.

However, the optimal name space may not be identical for every location in a program, and it is not possible to manage name spaces locally.

For instance, the language team has considered support for accessing enumerated values without having to use the name of the enumeration (so it would be monday rather than Days.monday).

An example of name space management which is at the core of object-orientation in general is the ability to access members of this in instance methods without including the word this.

This kind of name space management has been provided elsewhere as well, for instance in Kotlin function literals and types "with receiver" (here and here):

val repeatFun: String.(Int) -> String = { times -> this.repeat(times) }

This function can then be called using a method invocation syntax ("hello".repeatFun(3)), and it can be called as a regular function (repeatFun("hello", 3)). In the body of the function we can use this with type String, and at run time this is bound to the receiver (that is, the 1st argument for the regular function invocation).

Another example of a mechanism that adds a set of names to the current scope (such that id1.id2 can be abbreviated to id2) is the open construct in SML (see, e.g., p47 of this PDF).

All in all, the ability to give access to a certain name space in a specific scope is rather inhomogeneous and inconsistent in Dart, and there are a number of well-tested mechanism that we could use as a starting point for improvements in this area.

@eernstg eernstg added the request Requests to resolve a particular developer problem label Mar 13, 2019
This was referenced Mar 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Requests to resolve a particular developer problem
Projects
None yet
Development

No branches or pull requests

1 participant