-
Notifications
You must be signed in to change notification settings - Fork 329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reflector: use companion object apply method #487
Conversation
even when constructors are available
299cb71
to
cb9039a
Compare
Thanks, LGTM. |
Thanks for merging 馃帄 |
This reverts commit af8697d.
Hi @shanielh - thanks for this PR. I think it is very valuable. Unfortunately I have a suspicion, that it breaks Extraction.decompose() for the case, when case class is generic and apply() method in companion object has different signature than constructor of the case class. Something like object CaseClassWithCompanion {
def apply[A](v: A): CaseClassWithCompanion[A] = CaseClassWithCompanion(v, "Bar")
}
case class CaseClassWithCompanion[A](value: A, other: String) It throws
Do you think that this is a small fix, or maybe I should create another issue for this case? |
@eventuallyinconsistent Hi! I created a test case which doesn't seem to work as you told. I'll try to figure out what's wrong with it in the weekend. You should open an issue for this case 馃憤 |
even when constructors are available.
This is because
companion.apply(...)
in Scala has more power than secondary c'tors.Reflector
Maintainers: I had to change reflector to lookup the type parameters by name and not by instance because the apply method in scala (that is generated for case classes) has different instances of type parameters than those of the class. That means that if someone will create
Foo.apply[A](..)
forcase class Foo[B](..)
, it might not work. I can throw exception in that case, or whatever - Just let me know what you want, if you want this pull request 馃槃