diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2014-01-28 18:37:18 +0300 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2014-02-14 14:16:44 +0100 |
commit | 7fc77f83c873ce3fada0e01db4947caeb67527ab (patch) | |
tree | e11bf85dda7d13ea830ad5b7459d0056a89d1716 /.mailmap | |
parent | be22698fa2c1cf368efc8d2cf0f63100c6d0afdc (diff) | |
download | scala-7fc77f83c873ce3fada0e01db4947caeb67527ab.tar.gz scala-7fc77f83c873ce3fada0e01db4947caeb67527ab.tar.bz2 scala-7fc77f83c873ce3fada0e01db4947caeb67527ab.zip |
sane semantics for Symbols.companionSymbol
While playing with tests for Type.companionType, I figured out that
companionSymbol isn’t what it seems to be:
scala> ScalaPackage.companionSymbol
res5: $r.intp.global.Symbol = <none>
scala> ScalaPackageClass.companionSymbol
res6: $r.intp.global.Symbol = package scala
Or even funnier observation:
scala> class C; object C
defined class C
defined object C
scala> val classC = typeOf[C].typeSymbol
classC: $r.intp.global.Symbol = class C
scala> val moduleC = classC.companionSymbol
moduleC: $r.intp.global.Symbol = object C
scala> classC.companionSymbol == moduleC
res0: Boolean = true
scala> moduleC.companionSymbol == classC
res1: Boolean = true
scala> moduleC.moduleClass.companionSymbol == moduleC
res2: Boolean = true
Of course, I rushed to clean this up, so that `companionSymbol` only
returns something other than NoSymbol if the target has a companion in
the common sense, not wrt the internal “class with the same name in the
same package” convention of scalac, and that `companionSymbol` for
module classes is a class, not a source module.
Unfortunately it’s not that easy, because api.Symbol#companionSymbol
has the same name as internal.Symbol#companionSymbol, so we can’t change
the behavior of the former without changing the behavior of the latter.
Therefore I deprecated api.Symbol#companionSymbol and introduced a replacement
called api.Symbol#companion with sane semantics.
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions