Uploaded image for project: 'Suggestions'
  1. Suggestions
  2. SUGGEST-23

Support for case classes should be part of a library and extensible, just like everything in Scala

    Details

      Description

      Abstract: Declaring a case class saves boilerplate, but is inflexible because support for case classes is built-in. Various use cases require small variations of case classes. I argue that one should support them through a separate compiler plugin, activated by a "@case" annotation. Existing bugs which could be addressed should be linked here.

      Programming in Scala (2nd edition, Sec. 1.1 page 51) states that "Instead of providing all constructs you might ever need in one "perfectly complete" language, Scala puts the tools for building such constructs into your hands".
      However, case classes are an exception, and one often needs to generate only part of what "case" generates.
      More in general, since Scala provides nothing resembling a macro language, neither syntactic nor lexical abstractions, Scala's syntax has quite a number of complex special cases - for instance case classes.
      Lacking macros, Scala supports compiler plugins and annotations; I propose that case classes are deprecated and replaced by a plugin desugaring appropriate annotations and easy to extend.
      An even better alternative would be to implement case classes through something like Template Haskell.

        Attachments

          Issue Links

            Activity

            Hide
            burmako Eugene Burmako added a comment -

            You might be interested to learn about project Kepler: http://scalamacros.org/. Current SIP only involves macro defs: https://docs.google.com/document/d/1O879Iz-567FzVb8kw6N5OBpei9dnbW0ZaT7-XNSa6Cs/edit, but our future work might include macro types and macro annotations: http://scalamacros.org/future.html.

            Show
            burmako Eugene Burmako added a comment - You might be interested to learn about project Kepler: http://scalamacros.org/ . Current SIP only involves macro defs: https://docs.google.com/document/d/1O879Iz-567FzVb8kw6N5OBpei9dnbW0ZaT7-XNSa6Cs/edit , but our future work might include macro types and macro annotations: http://scalamacros.org/future.html .
            Hide
            retronym Jason Zaugg added a comment -

            Moved to [Suggestions]. There is interest in a-la-carte case class functionality, but this sort of things warrants a SIP. A good place to start is discussion on [scala-language]; the bug tracker has too limited an audience for this sort of discussion.

            Show
            retronym Jason Zaugg added a comment - Moved to [Suggestions] . There is interest in a-la-carte case class functionality, but this sort of things warrants a SIP. A good place to start is discussion on [scala-language] ; the bug tracker has too limited an audience for this sort of discussion.
            Hide
            pggiarrusso Paolo G. Giarrusso added a comment -

            Thanks, that's exactly what I hoped for. In particular, http://scalamacros.org/usecases/data-types-a-la-carte.html says that "certain auto-implementations are frequently useful on their own, but, currently, it's all or nothing - either you declare your class as a case class and live with all restrictions being imposed, or you don't get any of the auto-generated goodies", which is a good description of what I meant above.

            However, Odersky commented that case classes aren't as easy to generate through macros - http://www.scala-lang.org/node/8371#comment-35390 - but I guess that depends on the specific system (a macro transforming a class definition would be able to check if the user defines an equals method). Would your proposal be able to address this problem?

            Show
            pggiarrusso Paolo G. Giarrusso added a comment - Thanks, that's exactly what I hoped for. In particular, http://scalamacros.org/usecases/data-types-a-la-carte.html says that "certain auto-implementations are frequently useful on their own, but, currently, it's all or nothing - either you declare your class as a case class and live with all restrictions being imposed, or you don't get any of the auto-generated goodies", which is a good description of what I meant above. However, Odersky commented that case classes aren't as easy to generate through macros - http://www.scala-lang.org/node/8371#comment-35390 - but I guess that depends on the specific system (a macro transforming a class definition would be able to check if the user defines an equals method). Would your proposal be able to address this problem?
            Hide
            pggiarrusso Paolo G. Giarrusso added a comment -

            Jason Zaugg: sorry, missed your comment. However, if Eugene's is already planning to address this, I have nothing to add by opening a new discussion on scala-language. I hope the bugtracker entry is good as a meta-bug for issues like SI-5605.

            Show
            pggiarrusso Paolo G. Giarrusso added a comment - Jason Zaugg: sorry, missed your comment. However, if Eugene's is already planning to address this, I have nothing to add by opening a new discussion on scala-language. I hope the bugtracker entry is good as a meta-bug for issues like SI-5605 .
            Hide
            burmako Eugene Burmako added a comment -

            Paolo, yes, that depends on a macro system. Some macro systems are limited to expressions, some are not. Currently, project Kepler is limited to expressions, but I hope to address type generation/manipulation at some point in the future.

            Show
            burmako Eugene Burmako added a comment - Paolo, yes, that depends on a macro system. Some macro systems are limited to expressions, some are not. Currently, project Kepler is limited to expressions, but I hope to address type generation/manipulation at some point in the future.
            Hide
            pggiarrusso Paolo G. Giarrusso added a comment - - edited

            An update on the status: Eugene's Scala'13 paper mentions this in one of the examples. I've also found an implementation here: https://github.com/scalamacros/paradise/blob/2.10.3/tests/src/main/scala/kase.scala

            However, we should have an external library prototyping that. Also, we should split @kase into independent annotations. Eugene, are there already plans for that?

            Show
            pggiarrusso Paolo G. Giarrusso added a comment - - edited An update on the status: Eugene's Scala'13 paper mentions this in one of the examples. I've also found an implementation here: https://github.com/scalamacros/paradise/blob/2.10.3/tests/src/main/scala/kase.scala However, we should have an external library prototyping that. Also, we should split @kase into independent annotations. Eugene, are there already plans for that?
            Hide
            burmako Eugene Burmako added a comment -

            The @kase annotation was just a prototype, without any specific plans to turn it into a standalone library at that moment. That's a good idea though, but I will probably not have time for it in the upcoming months. If you would be interested in hacking this thing yourself, I'd do my best to help.

            Show
            burmako Eugene Burmako added a comment - The @kase annotation was just a prototype, without any specific plans to turn it into a standalone library at that moment. That's a good idea though, but I will probably not have time for it in the upcoming months. If you would be interested in hacking this thing yourself, I'd do my best to help.
            Hide
            sethtisue Seth Tisue added a comment -

            Your input is appreciated, but I'm afraid we are no longer accepting "Suggestion" tickets on JIRA.
            Available mechanisms for making suggestions include:

            • the Scala mailing lists
            • SIP (Scala Improvement Process) and SLIP (Scala Library Improvement Process)
            • a pull request on GitHub implementing the suggestion
            Show
            sethtisue Seth Tisue added a comment - Your input is appreciated, but I'm afraid we are no longer accepting "Suggestion" tickets on JIRA. Available mechanisms for making suggestions include: the Scala mailing lists SIP (Scala Improvement Process) and SLIP (Scala Library Improvement Process) a pull request on GitHub implementing the suggestion

              People

              • Assignee:
                Unassigned
                Reporter:
                pggiarrusso Paolo G. Giarrusso
              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: