Case class companion objects extending FunctionN in line with SLS?

131 views
Skip to first unread message

Andrew Phillips

unread,
Dec 15, 2016, 12:19:45 AM12/15/16
to scala-language
Hi all

As far as I can see from usage and -print REPL output, the generated companion object for a case class with N parameters is a subclass of FunctionN (2.11.6 REPL):

scala> :set -print

scala> case class Foo()
[[syntax trees at end of                   cleanup]] // <console>
...
  <synthetic> object iw$Foo extends scala.runtime.AbstractFunction0 with Serializable {

scala> case class Bar(n: Int)
[[syntax trees at end of                   cleanup]] // <console>
...
  <synthetic> object iw$Bar extends scala.runtime.AbstractFunction1 with Serializable {

scala> List(1, 2) map Bar
res0: List[Bar] = List(Bar(1), Bar(2))

SLS 5.3.2 [1] does not, as far as I can make out, say anything about this. The extractor object as defined there behaves differently from the one generate by the compiler:

scala> :paste
// Entering paste mode (ctrl-D to finish)

// not a case class; define the extractor as described in SLS explicitly
class Baz(n: Int)
object Baz {
  def apply(n: Int): Baz = new Baz(n)
  // other stuff
}

// Exiting paste mode, now interpreting.

defined class Baz
defined object Baz

scala> List(1, 2) map Baz
<console>:12: error: type mismatch;
 found   : Baz.type
 required: Int => ?
              List(1, 2) map Baz
                             ^
Is this a misreading/-understanding? If not, would this be considered a compiler bug, a spec omission or something else?

Regards

ap

Adriaan Moors

unread,
Dec 20, 2016, 7:46:35 PM12/20/16
to scala-language

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andrew Phillips

unread,
Dec 21, 2016, 8:04:34 AM12/21/16
to scala-language
Ah, thanks for the links, Adriaan! Going through the discussion threads, I'm not quite clear how to summarize the "something else" that you refer to ;-) There are a couple of comments that categorize this as spec omissions, and others that point to this being deliberately not in the spec, and rather an "implementation side-effect" that one presumably shouldn't rely on.

Could you confirm if either of those two is the correct interpretation?

Thanks!

ap

Adriaan Moors

unread,
Dec 21, 2016, 11:26:29 AM12/21/16
to scala-language
I was making a silly joke ;-) You give me three options and I can pick either one? Is this some kind of off-by-one puzzler :-D

Seriously, though, I can see the appeal, but as it stands, it's an historic artifact or implementation detail/quirk (it's tricky to add parents to existing companion objects). 

I agree it's surprising that some but not all companions inherit FunctionN (though user-defined companions are treated differently in other ways too). The original intent was to remove this surprise by not adding synthetic parents to any companion. We currently don't have plans to change this though. Ultimately, it would be great to see a shapeless-light SIP that allows generically traversing structures of case classes.

cheers
adriaan

--

martin odersky

unread,
Dec 21, 2016, 12:35:11 PM12/21/16
to scala-l...@googlegroups.com
On Wed, Dec 21, 2016 at 5:26 PM, Adriaan Moors <adr...@lightbend.com> wrote:
I was making a silly joke ;-) You give me three options and I can pick either one? Is this some kind of off-by-one puzzler :-D

Seriously, though, I can see the appeal, but as it stands, it's an historic artifact or implementation detail/quirk (it's tricky to add parents to existing companion objects). 

I agree it's surprising that some but not all companions inherit FunctionN (though user-defined companions are treated differently in other ways too). The original intent was to remove this surprise by not adding synthetic parents to any companion. We currently don't have plans to change this though. Ultimately, it would be great to see a shapeless-light SIP that allows generically traversing structures of case classes.

Yes, that would be nice indeed! 

 - Martin
 
cheers
adriaan

On Wed, Dec 21, 2016 at 5:04 AM Andrew Phillips <share...@gmail.com> wrote:
Ah, thanks for the links, Adriaan! Going through the discussion threads, I'm not quite clear how to summarize the "something else" that you refer to ;-) There are a couple of comments that categorize this as spec omissions, and others that point to this being deliberately not in the spec, and rather an "implementation side-effect" that one presumably shouldn't rely on.

Could you confirm if either of those two is the correct interpretation?

Thanks!

ap

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Martin Odersky
EPFL and Lightbend

Andrew Phillips

unread,
Dec 22, 2016, 4:23:50 AM12/22/16
to scala-language
> It's something else, that :-)

Doh! Humour failure, sorry - totally missed that ;-)

Thanks for the follow-up clarification.

ap
Reply all
Reply to author
Forward
0 new messages