www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] modules vs filenames in "module-name == filename" package systems

reply "Nick Sabalausky" <a a.a> writes:
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.
Jun 29 2010
next sibling parent reply Todd VanderVeen <tdv part.net> writes:
== 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.
Jun 29 2010
parent Todd VanderVeen <tdv part.net> writes:
== 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.
Jun 29 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jun 29 2010
parent reply Todd VanderVeen <tdv part.net> writes:
== 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.
Jun 29 2010
parent Todd VanderVeen <tdv part.net> writes:
== 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.
Jun 29 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Jul 08 2010