¿Qué son los paquetes anidados/no certificados en Scala 2.8?

package scala-2.8

Question

En Scala 2.7, podría escribir:

package com.acme.bar

class Bar

.

package com.acme.foo

class Foo {
  new bar.Bar
}

Esto no se compila en Scala 2.8 - sin embargo esto hace:

package com.acme 
package bar

class Bar

.

package com.acme
package foo

class Foo {
  new bar.Bar
}

1. ¿Cuál fue la motivación para esto?
2. ¿Cuál es el significado preciso con respecto al alcance y la visibilidad?
3. ¿Cuándo debo usar una forma sobre la otra?

Answer 1

¡Gracias por las respuestas hasta ahora! Déjame agregar dos pequeños puntos, y hemos terminado!

Visibilidad

La diferencia entre paquetes anidados y no anidados solo se aplica al alcance. La visibilidad siempre se basa en paquetes anidados.

package A

private[A] trait Secret

Esto funciona:

package A
package B

trait AB extends Secret

Así hace esto:

package A.B

trait AB extends A.Secret

En ambos casos, la estructura se interpreta como:

package A {
  trait Secret
  package B {
     //...
  }
}

Alcance

Compare esto con el alcance , en el que podría imaginar esta interpretación para paquetes no anidados:

package A {
  private [A] trait Secret
}

package `A.B` {
   trait AB extends A.Secret

}

Mezclar y combinar

Puede mezclar arbitrariamente y combinar paquetes anidados y no anidados:

package com.acme.project
package util.shazam
package blerg

Answer 2

¿No le da más control sobre lo que se está importando? Por ejemplo, si hubiera paquetes:

package com.acme.foo.client
package com.acme.client

Y luego, desde el interior de Foo , ¿no había una ambigua ambigüedad sobre a qué client se refería? Por ejemplo, si desea realizar una importación de comodines desde Foo :

class Foo {
  import client._ //what is being imported?
}

Esto podría ser mucho más problemático si, en lugar del client , tuviéramos un paquete com.acme.java :

class Foo {
    val jul = new java.util.LinkedList //compile error; cannot find util
}

Answer 3

Hubo varias discusiones largas en las listas de correo sobre esto. Vea este hilo para el problema y este hilo para la solución .

En cuanto al significado, sólo el

package A
package B

form abrirá un ámbito para A , que hace que los miembros de A visibles sin prefijo. Normalmente utilizaría este formulario si su proyecto consta de varios subpaquetes que se refieren entre sí. Por otro lado, utilizarías el formulario.

package A.B.C

Si desea integrar C en la jerarquía de paquetes y no tiene la intención de acceder a otros miembros de A o B directamente. Un caso típico es

package net.myorg.myproject

En este caso, no desea ser vulnerable a la posibilidad de que otra persona haya definido un paquete net.java que podría ocultar el nivel raíz de Java. En Scala 2.7 usted evitaría eso usando _root_ importaciones. Pero eso es feo, y para estar seguro tendrías que hacer esto en casi todas partes. Así que la solución actual es mucho mejor, OMI.