This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Nested package scopes vs. Imports (Was: Revisiting absolute/relative paths)

2 replies
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.

Can you put code before the subsequent package statements?

-------------------------------------
martin odersky wrote:

On Fri, Jul 17, 2009 at 10:33 AM, martin odersky wrote:
> On Thu, Jul 16, 2009 at 8:35 PM, David MacIver wrote:
>> 2009/7/16 Erkki Lindpere :
>>> Are we talking about
>>>
>>> package foo.bar
>>> import foo._
>>>
>>> as the equivalent of
>>> package foo {
>>> package bar {
>>> }
>>> }
>>> ?
>>
>> Yes.
>>
>>> Might be good enough, although I'd prefer not to duplicate 'foo' (if it
>>> might actually be longer). What about this (someone already propsed that I
>>> think):
>>> package `com.foo`.bar
>>
>> not thrilled with it to be honest. It's a fairly non-obvious meaning
>> for it to have.
>>
>> How about the following:
>>
>> package foo
>> package bar
>>
>> currently this is a compile error: You're not allowed more than one
>> braceless package per file. It could instead be interpreted so that
>> these nest, with the close braces happening right before EOF. i.e.
>>
>> package foo
>> package bar
>>
> Since the import syntax achieves effectively the same thing I don't
> think we need this alternative nested package syntax.
>
I retract on that. I have now an experimental version running which
implements the new proposal and have compiled the scala core libraries
and compiler with it. I noted that:

- nested packages are really very, very common; basically every
project uses them.
- having to insert imports becomes cumbersome because it's repetitive. Compare

package net.mycompany.mydepartment.myproject.partA.subpartB
import net.mycompany.mydepartment.myproject._
import net.mycompany.mydepartment.myproject.partA._

with

package net.mycompany.mydepartment.myproject
package partA
package subPartB

So I think I'm ready to commit to the proposal with this variation. I
quite the like fact that
pulling something into a scope of visibility requires an explicit
declaration. So I think we have a net win here.
.
We'll still have to write a SIP document, I guess. If people want to
help with that, this would be appreciated

Thanks to everyone for the constructive discussion!

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested package scopes vs. Imports (Was: Revisiting absolut

-------------------------------------
Naftoli Gugenheim wrote:

So it's like one long statement? What about "," instead of "package" as a separator?

-------------------------------------
martin odersky wrote:

On Fri, Jul 17, 2009 at 11:54 PM, Naftoli Gugenheim wrote:
> Can you put code before the subsequent package statements?
>
No.

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested package scopes vs. Imports (Was: Revisiting absolut

+1 (doesn't have to be instead)

-------------------------------------
Miles Sabin wrote:

On Fri, Jul 17, 2009 at 10:39 PM, martin odersky wrote:
> I retract on that. I have now an experimental version running which
> implements the new proposal and have compiled the scala core libraries
> and compiler with it. I noted that:
>
>  - nested packages are really very, very common; basically every
> project uses them.
>  - having to insert imports becomes cumbersome because it's repetitive. Compare
>
>   package net.mycompany.mydepartment.myproject.partA.subpartB
>   import net.mycompany.mydepartment.myproject._
>   import net.mycompany.mydepartment.myproject.partA._
>
>  with
>
>   package net.mycompany.mydepartment.myproject
>   package partA
>   package subPartB

Perhaps, but on the other hand, couldn't we instead enhance imports a little?

package net.mycompany.mydepartment.myproject.partA.subpartB

import net.mycompany.mydepartment.{ myproject.{ _, partA._ } }

I've wanted an extension to the import syntax along these lines on
many occasions quite independently of the the current issue.

Cheers,

Miles

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland