In a language that has a package system that forces package names to be the same as the directory name, and module names to be the same the file name (Such as Java, but not D): What is the point of having packages/modules instead of just simply importing by a relative filepath? Is it just so that it's consistent with refering to a symbol by it's fully-qualified name, or forcibly disallowing absolute paths when importing, or are there other reasons?

-------------------------------
Not sent from an iPhone.

== Quote from Nick Sabalausky (a@a.a)'s article
> In a language that has a package system that forces package names to be the same as the directory name, and module names to be the same the file name (Such as Java, but not D): What is the point of having packages/modules instead of just simply importing by a relative filepath? Is it just so that it's consistent with refering to a symbol by it's fully-qualified name, or forcibly disallowing absolute paths when importing, or are there other reasons?
> -------------------------------
> Not sent from an iPhone.

Java supports mobile code. Class loaders can resolve code over the network, not against a relative filesystem. The Java package naming convention is based on a reversed URL for an organization (e.g. com.myorg.whatever), which is presumably unique. It servers as a namespace mechanism.

== Quote from Todd VanderVeen (tdv@part.net)'s article
> == Quote from Nick Sabalausky (a@a.a)'s article
> > In a language that has a package system that forces package names to be the same as the directory name, and module names to be the same the file name (Such as Java, but not D): What is the point of having packages/modules instead of just simply importing by a relative filepath? Is it just so that it's consistent with refering to a symbol by it's fully-qualified name, or forcibly disallowing absolute paths when importing, or are there other reasons?
> > -------------------------------
> > Not sent from an iPhone.
> Java supports mobile code. Class loaders can resolve code over the network, not against a relative filesystem. The Java package naming convention is based on a reversed URL for an organization (e.g. com.myorg.whatever), which is presumably unique. It servers as a namespace mechanism.

That should read "not only against relative filesystem". Obviously, it can do this too.

On Tue, 29 Jun 2010 14:51:49 -0400, Nick Sabalausky <a@a.a> wrote:

> In a language that has a package system that forces package names to be the
> same as the directory name, and module names to be the same the file name
> (Such as Java, but not D): What is the point of having packages/modules
> instead of just simply importing by a relative filepath? Is it just so that
> it's consistent with refering to a symbol by it's fully-qualified name, or
> forcibly disallowing absolute paths when importing, or are there other
> reasons?

Java doesn't import source files, it imports compiled objects.  Therefore, the file/module relationship is superficial -- you could just as easily create a java compiler that can compile all packages/modules in one file.  I think the file/directory model just is easy for people to understand and maintain.

D is different in that it actually requires the source for importing.

I've always hoped that D moved more towards an import model that used compiled objects instead of the source.  There's always the chance that objects are out of sync with source, and the compiler can add annotations for things like full escape analysis if what you import is always generated.

-Steve

== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> On Tue, 29 Jun 2010 14:51:49 -0400, Nick Sabalausky <a@a.a> wrote:
> > In a language that has a package system that forces package names to be
> > the
> > same as the directory name, and module names to be the same the file name
> > (Such as Java, but not D): What is the point of having packages/modules
> > instead of just simply importing by a relative filepath? Is it just so
> > that
> > it's consistent with refering to a symbol by it's fully-qualified name,
> > or
> > forcibly disallowing absolute paths when importing, or are there other
> > reasons?
> Java doesn't import source files, it imports compiled objects.  Therefore,
> the file/module relationship is superficial -- you could just as easily
> create a java compiler that can compile all packages/modules in one file.
> I think the file/directory model just is easy for people to understand and
> maintain.
> D is different in that it actually requires the source for importing.
> I've always hoped that D moved more towards an import model that used
> compiled objects instead of the source.  There's always the chance that
> objects are out of sync with source, and the compiler can add annotations
> for things like full escape analysis if what you import is always
> generated.
> -Steve

Java Class loaders observe the JVM class file format. This format in turn specifies that class and interface names always be fully qualified package names. The dependency resolution and dynamic binding mechanisms presumably rely upon this. Conceptually, this apparatus could be modified to support an alternate scheme, but the one class per file is not just superficial.

== Quote from Todd VanderVeen (tdv@part.net)'s article
> == Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> > On Tue, 29 Jun 2010 14:51:49 -0400, Nick Sabalausky <a@a.a> wrote:
> > > In a language that has a package system that forces package names to be
> > > the
> > > same as the directory name, and module names to be the same the file name
> > > (Such as Java, but not D): What is the point of having packages/modules
> > > instead of just simply importing by a relative filepath? Is it just so
> > > that
> > > it's consistent with refering to a symbol by it's fully-qualified name,
> > > or
> > > forcibly disallowing absolute paths when importing, or are there other
> > > reasons?
> > Java doesn't import source files, it imports compiled objects.  Therefore,
> > the file/module relationship is superficial -- you could just as easily
> > create a java compiler that can compile all packages/modules in one file.
> > I think the file/directory model just is easy for people to understand and
> > maintain.
> > D is different in that it actually requires the source for importing.
> > I've always hoped that D moved more towards an import model that used
> > compiled objects instead of the source.  There's always the chance that
> > objects are out of sync with source, and the compiler can add annotations
> > for things like full escape analysis if what you import is always
> > generated.
> > -Steve
> Java Class loaders observe the JVM class file format. This format in turn specifies that class and interface names always be fully qualified package names. The dependency resolution and dynamic binding mechanisms presumably rely upon this. Conceptually, this apparatus could be modified to support an alternate scheme, but the one class per file is not just superficial.

Steve,

I confused your statement "can compile all packages/modules in one file". I read that as compile into a class file, not compile from one source file. One public type per class file seems necessary to simplify identification during class loading and minimize network bandwidth, but one class per source file does seem superficial. This was apparently done to optimize the Oak compiler, i.e. avoid parsing the files to determine what types were present.

http://www.artima.com/weblogs/viewpost.jsp?thread=7555

Todd V.

On 29/06/2010 19:51, Nick Sabalausky wrote:
> In a language that has a package system that forces package names to be the
> same as the directory name, and module names to be the same the file name
> (Such as Java, but not D): What is the point of having packages/modules
> instead of just simply importing by a relative filepath? Is it just so that
> it's consistent with refering to a symbol by it's fully-qualified name, or
> forcibly disallowing absolute paths when importing, or are there other
> reasons?
>
> -------------------------------
> Not sent from an iPhone.
>
>

"forcibly disallowing absolute paths when importing"
Thats one reason.

Also:
* Enforcing imports of D files only, and not files with other extensions. As a consequence, no need to specify D file extension.
* Making it clear packages and modules names can only be valid D identifiers (ie, no spaces, non alphanumerical symbols, etc.)

Those are reasons enough I hope.

-- 
Bruno Medeiros - Software Engineer