Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn
Yeah, I was wrong about the constructor idea. Indeed it won't work due to the reasons that Roland described.Speaking of the solution, even if we made the private ctor work, it'd still be possible to circumvent it using reflection. Hence, I think, making the constructor public would do no harm.
As to enforcing properties, it depends on the definition. E.g. with macros we can validate string literals for conformance with domain-specific rules. Or by wrapping a body of a function in pure {...}, we can have the "pure" macro verify that the body is actually pure. I'm not Martin, of course :)
Well, .asInstanceOf[] and reflection are universally accepted ways of breaking all kinds of guarantees, whereas calling a public constructor is not.
Please don't use $ this way! It is a guarantee that when you use $
now, or devise any new ad hoc mangling at all, you create new bugs.
There is a chance we can make most of the name mangling problem go
away by taking advantage of symbolic freedom at the vm level, but even
if we do that, it will still be important that people not casually use
'$' for nonessential purposes. Java makes assumptions about '$' which
we cannot affect, and we have to honor those assumptions.
I wasn't suggesting the method is nonessential, but that the
application of '$' as a way to signal "don't use this, users" is
nonessential.
At the JVM level, the constructor is public in this case. I don't
remember the exact rules but I think anything other than private[this]
is not really made private in the bytecode.
C:\Users\szeiger\Desktop\stest>javap Static
Compiled from "Static.scala"
public final class Static extends java.lang.Object implements
scala.ScalaObject,scala.Product,scala.Serializable{
...
public Static(scala.Function1, scala.Product);
}