Classes that have names starting from dollars

On Wed, Feb 1, 2012 at 7:28 AM, Eugene Burmako wrote:
> Bottom line of this post is that getSimpleName will work incorrectly
> if class/object name intentionally starts with $. Is this something
> we're fine with?

We're not fine with any of it. We should not settle for anything
short of 100% compatibility with java reflection, by which I mean:
your program should not ever explode just because you called some
method on Class or Method.

But I don't think we can get there unless we reserve something beyond
$ for internal use. I would dearly like to do this. It will only get
more difficult from here. You can't imagine how many semantic
collisions we are amassing *internally* due to the use of the '$' for
every form of name encoding under the sun. That's before one adds the
constraint that we have to comply with java's hardcoded internal
implementation of getSimpleName, inner classes, anonymous classes, and
on and on.

See also:

https://issues.scala-lang.org/browse/SI-2806
"Name mangling has outstripped the abilities of lonesome '$$'"

https://issues.scala-lang.org/browse/SI-4316
"name mangling vs. java reflection"

Also take a moment to laugh/cry about "lonesome '$$'", not so lonesome
since the entire database was mangled. Imagine it to be infinitely
more lonesome and you get the original description.

On 1 February 2012 16:28, Eugene Burmako <eugene.burmako@epfl.ch> wrote:

...ask for troubles.

Say, we've got a class $line5.$read$$iw$$iw$ (generated by REPL) that
corresponds to the innermost $iw from:

package $line5

object $read {
 object $iw {
   object $iw {
     ...
   }
}

Enclosing class for this class is $line5.$read$$iw$ (which is
correct), so we'd expect getSimpleName to return $iw$. However, what
really gets returned is iw$, because Java strips all leading dollars
and numbers from the simple name.

A sad consequence of that is that stuff that relies on getSimpleName
will not work (currently, this affects reflection, but I'm going to
change that, so it's not that big of a deal).

Bottom line of this post is that getSimpleName will work incorrectly
if class/object name intentionally starts with $. Is this something
we're fine with?

Isn't it that we are going to have Scala reflection just to be able to avoid calls to getSimpleName? Corresponding method in Scala reflection should work, always, right?

--
Grzegorz Kossakowski

Sent from my phone

On Feb 1, 2012, at 16:36, Grzegorz Kossakowski <grzegorz.kossakowski@gmail.com> wrote:

On 1 February 2012 16:28, Eugene Burmako < (eugene [dot] burmako [at] epfl [dot] ch> wrote:

...ask for troubles.

Say, we've got a class $line5.$read$$iw$$iw$ (generated by REPL) that
corresponds to the innermost $iw from:

package $line5

object $read {
 object $iw {
   object $iw {
     ...
   }
}

Enclosing class for this class is $line5.$read$$iw$ (which is
correct), so we'd expect getSimpleName to return $iw$. However, what
really gets returned is iw$, because Java strips all leading dollars
and numbers from the simple name.

A sad consequence of that is that stuff that relies on getSimpleName
will not work (currently, this affects reflection, but I'm going to
change that, so it's not that big of a deal).

Bottom line of this post is that getSimpleName will work incorrectly
if class/object name intentionally starts with $. Is this something
we're fine with?

Isn't it that we are going to have Scala reflection just to be able to avoid calls to getSimpleName? Corresponding method in Scala reflection should work, always, right?

--

That should be the aim. It would be nice if all firms of Java reflection worked as well on.all kind is Scala Dara including synthesized ones. But failing that we should at least make sure that Scala reflection is bullet proof.
  Martin

Grzegorz Kossakowski

Speaking of bullet-proofness, this is what I'm implementing right now - no worries :)

On 1 February 2012 17:22, Martin Odersky <odersky@gmail.com> wrote:

Sent from my phone

On Feb 1, 2012, at 16:36, Grzegorz Kossakowski <grzegorz.kossakowski@gmail.com> wrote:

On 1 February 2012 16:28, Eugene Burmako <eugene.burmako@epfl.ch> wrote:

...ask for troubles.

Say, we've got a class $line5.$read$$iw$$iw$ (generated by REPL) that
corresponds to the innermost $iw from:

package $line5

object $read {
 object $iw {
   object $iw {
     ...
   }
}

Enclosing class for this class is $line5.$read$$iw$ (which is
correct), so we'd expect getSimpleName to return $iw$. However, what
really gets returned is iw$, because Java strips all leading dollars
and numbers from the simple name.

A sad consequence of that is that stuff that relies on getSimpleName
will not work (currently, this affects reflection, but I'm going to
change that, so it's not that big of a deal).

Bottom line of this post is that getSimpleName will work incorrectly
if class/object name intentionally starts with $. Is this something
we're fine with?

Isn't it that we are going to have Scala reflection just to be able to avoid calls to getSimpleName? Corresponding method in Scala reflection should work, always, right?

--

That should be the aim. It would be nice if all firms of Java reflection worked as well on.all kind is Scala Dara including synthesized ones. But failing that we should at least make sure that Scala reflection is bullet proof.
  Martin

Grzegorz Kossakowski