Case class companion objects extending FunctionN in line with SLS?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Case class companion objects extending FunctionN in line with SLS?

Andrew Phillips
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

[1] https://www.scala-lang.org/files/archive/spec/2.13/05-classes-and-objects.html#case-classes

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Case class companion objects extending FunctionN in line with SLS?

Adriaan Moors-7

On Wed, Dec 14, 2016 at 9:19 PM Andrew Phillips <[hidden email]> wrote:
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

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Case class companion objects extending FunctionN in line with SLS?

Andrew Phillips
> See also https://issues.scala-lang.org/browse/SI-3664https://issues.scala-lang.org/browse/SI-5570

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Case class companion objects extending FunctionN in line with SLS?

Adriaan Moors-7
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

On Wed, Dec 21, 2016 at 5:04 AM Andrew Phillips <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Case class companion objects extending FunctionN in line with SLS?

martin odersky-2


On Wed, Dec 21, 2016 at 5:26 PM, Adriaan Moors <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

Martin Odersky
EPFL and Lightbend

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Case class companion objects extending FunctionN in line with SLS?

Andrew Phillips
In reply to this post by Adriaan Moors-7
> It's something else, that :-)

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

Thanks for the follow-up clarification.

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.