为什么我们仍然在Groovy/Grails中使用package关键字？

在Java/Groovy中，afaik必须在相应的文件夹中定义一个包。这将导致存储在

/a/b/c

中的所有类文件都以

package a.b.c

行开头。这还需要吗？关于常规而非配置，这不是干的

---

当这个包定义是可选的时，会出现什么样的问题？

在Groovy（和Grails）中使用包的原因与在Java中使用包的原因相同

包用于将类组织到逻辑名称空间中，通常是通过将协作类分组在一起

它有助于避免与其他类（Java或Groovy）的命名冲突

---

在任何有成百上千个类的非传统系统中，包提供了一种非常有用的组织和结构机制。

我想你的意思是，包名由类所在的目录暗示，那么为什么需要明确地说明它呢？只有在某些情况下（如Grails）才是如此，其中有一个建立源文件根的约定（例如，

src/groovy

）

---

但是，假设我正在编写一个Groovy应用程序，并且有一个文件位于

/a/b/c/D.Groovy

，我们如何判断源文件的根是

/a

，因此包名是

b.c

，或者源文件的根是

/a/b

，因此包名就是

c

？据我所知，我们不能这样做，因此需要在源文件中明确说明包名。

虽然目录结构与包结构匹配是常规做法，如果它们不匹配，就会出现某些问题，但实际上并不要求它们匹配。Java也是如此（尽管很多人没有意识到这一点）

下面是一个例子来说明这一点

groovydemo $ mkdir classes
groovydemo $ 
groovydemo $ cat src/groovy/com/demo/SomeClass.groovy 
package com.somethingotherthandemo

class SomeClass {}
groovydemo $ 
groovydemo $ groovyc -d classes/ src/groovy/com/demo/SomeClass.groovy 
groovydemo $ find classes -type f
classes/com/somethingotherthandemo/SomeClass.class

---

是的，包的作用是已知的，但我试图问的是，如果通过文件系统中的位置已经知道包名，那么是否还需要指定包名……因此，在Grails中，我们知道根和包定义可以省略。但是，即使我们想到Groovy，构建脚本也必须知道源代码的根作为起点…@Ralf您的Groovy文件对构建配置一无所知请注意，src目录与包结构不匹配（demo vs.somethingotherthandemo）。编译器创建与包结构匹配的目录结构，并将.class文件放在那里，但源路径可以是任何内容。在大多数情况下，src路径与包结构不匹配是一个坏主意，但它是有效的。好吧，您自己写道“这是常规的”-进一步使用grails并使包成为可选和隐式的难道没有意义吗？这就是我所说的“约定结束…”不是配置，而是习惯…我不知道你所说的“让grails更进一步”是什么意思。Grails没有使包语句成为可选的。在Grails中，不包含package语句的类与其他环境一样位于默认包中。我认为这可能更好——文件夹可以对应于包，因此包声明可以是可选的（目前还不是）。但那只是我的想法。我只是想知道这是否可以通过一个全局AST转换来实现：-）使用您正在想象的编译器，在我上面展示的示例中，如果您删除了package语句，并且没有更改任何其他内容（没有命令行参数，没有其他更改），您会期望包是src.groovy.com.demo吗，Users.jeff.projects.groovydemo.src.groovy.com.demo、默认（空）包、编译错误或其他什么？