You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
andhide
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 thanDays.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 wordthis
.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):
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 usethis
with typeString
, and at run timethis
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 toid2
) is theopen
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.
The text was updated successfully, but these errors were encountered: