Skip to content

Commit 259332c

Browse files
oderskyodersky
committed
Introduce scalaShadowing package
The `scalaShadowing` package is used to safely modify classes and objects in scala so that they can be used from dotty. They will be visible as members of the `scala` package, replacing any objects or classes with the same name. But their binary artifacts are in `scalaShadowing` so they don't clash with the same-named `scala` members at runtime.
1 parent 3e76f3c commit 259332c

File tree

2 files changed

+213
-0
lines changed

2 files changed

+213
-0
lines changed

‎src/dotty/tools/dotc/core/Definitions.scala

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -140,6 +140,16 @@ class Definitions {
140140
lazy val Sys_errorR = SysPackage.moduleClass.requiredMethodRef(nme.error)
141141
def Sys_error(implicit ctx: Context) = Sys_errorR.symbol
142142

143+
/** The `scalaShadowing` package is used to safely modify classes and
144+
* objects in scala so that they can be used from dotty. They will
145+
* be visible as members of the `scala` package, replacing any objects
146+
* or classes with the same name. But their binary artifacts are
147+
* in `scalaShadowing` so they don't clash with the same-named `scala`
148+
* members at runtime.
149+
*/
150+
lazy val ScalaShadowingPackageVal = ctx.requiredPackage("scalaShadowing")
151+
lazy val ScalaShadowingPackageClass = ScalaShadowingPackageVal.moduleClass.asClass
152+
143153
/** Note: We cannot have same named methods defined in Object and Any (and AnyVal, for that matter)
144154
* because after erasure the Any and AnyVal references get remapped to the Object methods
145155
* which would result in a double binding assertion failure.
@@ -781,6 +791,11 @@ class Definitions {
781791
if (!_isInitialized) {
782792
// force initialization of every symbol that is synthesized or hijacked by the compiler
783793
val forced = syntheticCoreClasses ++ syntheticCoreMethods ++ ScalaValueClasses()
794+
795+
// Enter all symbols from the scalaShadowing package in the scala package
796+
for (m <- ScalaShadowingPackageClass.info.decls)
797+
ScalaPackageClass.enter(m)
798+
784799
_isInitialized = true
785800
}
786801
}

‎src/scalaShadowing/language.scala

Lines changed: 198 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,198 @@
1+
/* __ *\
2+
** ________ ___ / / ___ Scala API **
3+
** / __/ __// _ | / / / _ | (c) 2003-2015, LAMP/EPFL **
4+
** __\ \/ /__/ __ |/ /__/ __ | http://scala-lang.org/ **
5+
** /____/\___/_/ |_/____/_/ | | **
6+
** |/ **
7+
\* */
8+
package scalaShadowing
9+
10+
/**
11+
* The `scala.language` object controls the language features available to the programmer, as proposed in the
12+
* [[https://docs.google.com/document/d/1nlkvpoIRkx7at1qJEZafJwthZ3GeIklTFhqmXMvTX9Q/edit '''SIP-18 document''']].
13+
*
14+
* Each of these features has to be explicitly imported into the current scope to become available:
15+
* {{{
16+
* import language.postfixOps // or language._
17+
* List(1, 2, 3) reverse
18+
* }}}
19+
*
20+
* The language features are:
21+
* - [[dynamics `dynamics`]] enables defining calls rewriting using the [[scala.Dynamic `Dynamic`]] trait
22+
* - [[postfixOps `postfixOps`]] enables postfix operators
23+
* - [[reflectiveCalls `reflectiveCalls`]] enables using structural types
24+
* - [[implicitConversions `implicitConversions`]] enables defining implicit methods and members
25+
* - [[higherKinds `higherKinds`]] enables writing higher-kinded types
26+
* - [[existentials `existentials`]] enables writing existential types
27+
* - [[experimental `experimental`]] contains newer features that have not yet been tested in production
28+
*
29+
* and, for dotty:
30+
*
31+
* - [[Scala2 `Scala2`] backwards compatibility mode for Scala2
32+
* - [[noAtoTupling `noAutoTupling`]] disable auto-tupling
33+
*
34+
* @groupname production Language Features
35+
* @groupname experimental Experimental Language Features
36+
* @groupprio experimental 10
37+
*
38+
* Dotty-specific features come at the end.
39+
*
40+
* Note: Due to the more restricted language import mechanism in dotty (only
41+
* imports count, implicits are disregarded) we don't need the constructions
42+
* of the inherited language features. A simple object for each feature is
43+
* sufficient.
44+
*/
45+
object language {
46+
47+
import languageFeature._
48+
49+
/** Where enabled, direct or indirect subclasses of trait scala.Dynamic can
50+
* be defined. Unless dynamics is enabled, a definition of a class, trait,
51+
* or object that has Dynamic as a base trait is rejected. Dynamic member
52+
* selection of existing subclasses of trait Dynamic are unaffected;
53+
* they can be used anywhere.
54+
*
55+
* '''Why introduce the feature?''' To enable flexible DSLs and convenient interfacing
56+
* with dynamic languages.
57+
*
58+
* '''Why control it?''' Dynamic member selection can undermine static checkability
59+
* of programs. Furthermore, dynamic member selection often relies on reflection,
60+
* which is not available on all platforms.
61+
*
62+
* @group production
63+
*/
64+
@volatile implicit lazy val dynamics: dynamics = languageFeature.dynamics
65+
66+
/** Only where enabled, postfix operator notation `(expr op)` will be allowed.
67+
*
68+
* '''Why keep the feature?''' Several DSLs written in Scala need the notation.
69+
*
70+
* '''Why control it?''' Postfix operators interact poorly with semicolon inference.
71+
* Most programmers avoid them for this reason.
72+
*
73+
* @group production
74+
*/
75+
@volatile implicit lazy val postfixOps: postfixOps = languageFeature.postfixOps
76+
77+
/** Only where enabled, accesses to members of structural types that need
78+
* reflection are supported. Reminder: A structural type is a type of the form
79+
* `Parents { Decls }` where `Decls` contains declarations of new members that do
80+
* not override any member in `Parents`. To access one of these members, a
81+
* reflective call is needed.
82+
*
83+
* '''Why keep the feature?''' Structural types provide great flexibility because
84+
* they avoid the need to define inheritance hierarchies a priori. Besides,
85+
* their definition falls out quite naturally from Scala’s concept of type refinement.
86+
*
87+
* '''Why control it?''' Reflection is not available on all platforms. Popular tools
88+
* such as ProGuard have problems dealing with it. Even where reflection is available,
89+
* reflective dispatch can lead to surprising performance degradations.
90+
*
91+
* @group production
92+
*/
93+
@volatile implicit lazy val reflectiveCalls: reflectiveCalls = languageFeature.reflectiveCalls
94+
95+
/** Only where enabled, definitions of implicit conversions are allowed. An
96+
* implicit conversion is an implicit value of unary function type `A => B`,
97+
* or an implicit method that has in its first parameter section a single,
98+
* non-implicit parameter. Examples:
99+
*
100+
* {{{
101+
* implicit def stringToInt(s: String): Int = s.length
102+
* implicit val conv = (s: String) => s.length
103+
* implicit def listToX(xs: List[T])(implicit f: T => X): X = ...
104+
* }}}
105+
*
106+
* implicit values of other types are not affected, and neither are implicit
107+
* classes.
108+
*
109+
* '''Why keep the feature?''' Implicit conversions are central to many aspects
110+
* of Scala’s core libraries.
111+
*
112+
* '''Why control it?''' Implicit conversions are known to cause many pitfalls
113+
* if over-used. And there is a tendency to over-use them because they look
114+
* very powerful and their effects seem to be easy to understand. Also, in
115+
* most situations using implicit parameters leads to a better design than
116+
* implicit conversions.
117+
*
118+
* @group production
119+
*/
120+
@volatile implicit lazy val implicitConversions: implicitConversions = languageFeature.implicitConversions
121+
122+
/** Only where this flag is enabled, higher-kinded types can be written.
123+
*
124+
* '''Why keep the feature?''' Higher-kinded types enable the definition of very general
125+
* abstractions such as functor, monad, or arrow. A significant set of advanced
126+
* libraries relies on them. Higher-kinded types are also at the core of the
127+
* scala-virtualized effort to produce high-performance parallel DSLs through staging.
128+
*
129+
* '''Why control it?''' Higher kinded types in Scala lead to a Turing-complete
130+
* type system, where compiler termination is no longer guaranteed. They tend
131+
* to be useful mostly for type-level computation and for highly generic design
132+
* patterns. The level of abstraction implied by these design patterns is often
133+
* a barrier to understanding for newcomers to a Scala codebase. Some syntactic
134+
* aspects of higher-kinded types are hard to understand for the uninitiated and
135+
* type inference is less effective for them than for normal types. Because we are
136+
* not completely happy with them yet, it is possible that some aspects of
137+
* higher-kinded types will change in future versions of Scala. So an explicit
138+
* enabling also serves as a warning that code involving higher-kinded types
139+
* might have to be slightly revised in the future.
140+
*
141+
* @group production
142+
*/
143+
@volatile implicit lazy val higherKinds: higherKinds = languageFeature.higherKinds
144+
145+
/** Only where enabled, existential types that cannot be expressed as wildcard
146+
* types can be written and are allowed in inferred types of values or return
147+
* types of methods. Existential types with wildcard type syntax such as `List[_]`,
148+
* or `Map[String, _]` are not affected.
149+
*
150+
* '''Why keep the feature?''' Existential types are needed to make sense of Java’s wildcard
151+
* types and raw types and the erased types of run-time values.
152+
*
153+
* '''Why control it?''' Having complex existential types in a code base usually makes
154+
* application code very brittle, with a tendency to produce type errors with
155+
* obscure error messages. Therefore, going overboard with existential types
156+
* is generally perceived not to be a good idea. Also, complicated existential types
157+
* might be no longer supported in a future simplification of the language.
158+
*
159+
* @group production
160+
*/
161+
@volatile implicit lazy val existentials: existentials = languageFeature.existentials
162+
163+
/** The experimental object contains features that have been recently added but have not
164+
* been thoroughly tested in production yet.
165+
*
166+
* Experimental features '''may undergo API changes''' in future releases, so production
167+
* code should not rely on them.
168+
*
169+
* Programmers are encouraged to try out experimental features and
170+
* [[http://issues.scala-lang.org report any bugs or API inconsistencies]]
171+
* they encounter so they can be improved in future releases.
172+
*
173+
* @group experimental
174+
*/
175+
object experimental {
176+
177+
import languageFeature.experimental._
178+
179+
/** Where enabled, macro definitions are allowed. Macro implementations and
180+
* macro applications are unaffected; they can be used anywhere.
181+
*
182+
* '''Why introduce the feature?''' Macros promise to make the language more regular,
183+
* replacing ad-hoc language constructs with a general powerful abstraction
184+
* capability that can express them. Macros are also a more disciplined and
185+
* powerful replacement for compiler plugins.
186+
*
187+
* '''Why control it?''' For their very power, macros can lead to code that is hard
188+
* to debug and understand.
189+
*/
190+
@volatile implicit lazy val macros: macros = languageFeature.experimental.macros
191+
}
192+
193+
/** Where imported, a backwards compatibility mode for Scala2 is enabled */
194+
object Scala2
195+
196+
/** Where imported, auto-tupling is disabled */
197+
object noAutoTupling
198+
}

0 commit comments

Comments
 (0)