I've found this useful for tests ... I suspect I'm not the only one.
I’m primarily aiming at dropping the incremental package declarations like:
package com; package foo; package bar;
Multiple scoped ones in one file, not sure if they pose a tooling problem.
On Wed, Nov 22, 2017 at 11:59 Miles Sabin notifications@github.com wrote:
I've found this useful for tests ... I suspect I'm not the only one.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scala/scala-dev/issues/440#issuecomment-346458336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFjy1gY76AgaNYbM0Osm4h3BDEfebruks5s5H0PgaJpZM4QlHzz
.
I use those throughout - my - code - base TBH.
I've found it very convenient to do similar things:
package com.foo.baz
package internal
and now all of the (external) declarations in com.foo.baz are in scope. Obviously I can just say
package com.foo.baz.internal
import com.foo.baz._
but it feels more like internal is _part_ of com.foo.baz, which is subjectively nice.
Multiple scoped ones in one file, not sure if they pose a tooling problem.
What's the benefit in the compiler of dropping them?
It's not really a problem for the compiler, but a code formatter needs to consider this when rewriting imports. With all these tickets, I'm trying to reopen the discussion and pretend we were about to add those features, and ask ourselves, with the benefit of hindsight, is the added convenience worth the complexity?
Most helpful comment
It's not really a problem for the compiler, but a code formatter needs to consider this when rewriting imports. With all these tickets, I'm trying to reopen the discussion and pretend we were about to add those features, and ask ourselves, with the benefit of hindsight, is the added convenience worth the complexity?