Drop package objects with inheritance

[adriaanm]

Replace with support for top-level definitions?

[olafurpg]

Can you elaborate on the issues with supporting package objects?

This would be a fairly breaking change for libraries like Scalameta that use package objects + inheritance to expose the same api through multiple namespaces https://github.com/scalameta/scalameta/blob/23de1ca839e53ad6387981bd7cced35122a2cf76/scalameta/scalameta/shared/src/main/scala/scala/meta/package.scala#L3-L14
For example, import scala.meta._ imports all scalameta modules while if you can depend only on the parsers package and import scala.meta.parsers._.

For migration, we could require users to add an explicit import on the package object

import scala.meta.`package`._
import scala.meta._

Would it be possible to simplify the implementation of package objects in the compiler to perform a similar desugaring?

[dwijnand]

In sbt we also use package object inheritance to compose the namespace that import sbt._ gives you:

https://github.com/sbt/sbt/blob/v1.1.0-M1/sbt/src/main/scala/package.scala#L6-L20

So I think namespace composition is a feature that should be preserved in some fashion.

On the other hand I'm also very much in favour of the ability to define top-level definitions! 💯

[nafg]

If someone revives the long-ago proposed notion of "exports" (dual of imports), it might solve some of the above use cases

[adriaanm]

I was thinking about exports too, as an alternative, but it occurred to me they're likely worse then package objects that can inherit definitions when it comes to having at least some phase distinction between constructing the outline of the symbol table and full on type checking. With exports, you'd have to do full type checking (unless you restrict them to fully qualified references to packages), just to determine an outline of the packages and their top-level definitions.

That's also the main problem of inheritance for package objects: what does it even mean for a package object to inherit from a class that's inside the package that we're defining?

/cc @retronym, could you expand on this? Feel free to edit the issue description

[dwijnand]

If it's useful, here's a ticket where @gkossakowski fixed a package object + inheritance issue in sbt 0.13's zinc: sbt/sbt#2326.

[szeiger]

Removing package object inheritance also prevents you from scoping implicits with different priorities into a package.

[megri]

This is "kinda" (add quotes to taste) like a suggestion I made a while ago: scala/scala3#1882

I never felt like package objects were ergonomical but felt like they were a crutch to get top level definitions into a namespace.

The comment about import priorities is interesting but that kinda feels like a crutch too..

[dwijnand]

@adriaanm Is this ticket about dropping the ability to use inheritance in package objects, or dropping package objects entirely - because of issues with inheritance?

I first understood this to mean the former, but I see the latest SIP meeting agenda and minutes refer to this topic as "Remove package objects": http://docs.scala-lang.org/sips/minutes/2017-12-06-sip-minutes.html#to-be-discussed, and you crossing out package objects in https://adriaanm.github.io/reveal.js/scala-2.13-beyond.html#/7/3.

Thanks.

[megri]

I've given my proposal from a year ago some more thought. Not sure if it's the proper place but as my original issue is now closed I created a gist: https://gist.github.com/megri/22bf37fb6406ff104de18c58ff0a6404

It deals with top level definitions and restrictions of implicits in a somewhat controlled way.

[SethTisue]

(this was discussed by the SIP committee at the SIP meeting this week, but the notes haven't been published yet)

[soronpo]

I think the main use-case for inheritance in package objects is to save the user from multiple import statements, yet still maintain proper code distribution across files. So I'm proposing a new language feature which is fairly simple, I think.
Lets introduce an import alias (or bundle). Meaning, if I have import theEntireLib = import myLib.{core._, implicits._, otherStuff._}, and I use import theEntireLib then that's just syntactic sugar for import myLib.{core._, implicits._, otherStuff._}.
You can limit the alias to the scope of the package it resides in, so people can't just import several libraries in one import alias (creating a huge binary as the sum of all those libraries).