Concerning in D the whole aspect of imports, packages, modules and symbol name scopes, etc.(what to call this whole thing?) there are some things I find ill-conceived, so much that I think this aspect of D is in need of some rethinking.


First: more often than not, I like to access a symbol using its "fully qualified name" (what to call it?), like this:
package1.module1.func(module2.var1);

Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
The first alternative that came to mind was to change import so that it would do so: make the symbols accessible only by FQN, and then we would have a /using/ statement, same as C++, that would bring packages or modules to the local scope (and that would replace the /with/ statement).

But then I realized, why do we then even need the imports at all? Why not automatically import all available modules (into FQN scope), and just use the /using/ keyword when we want to bring external scopes closer? (Are we still thinking C++ legacy-like here?...) It's the simple logical conclusion. Simple and in fact nothing new, as both Java and C# do it this way, which further assures me this is a better behaviour.

This feature requires an import path, i.e. a list of directories where to search and import the symbol names (in Java this is the CLASSPATH). In D this would be the already existant path defined by the -I command-line options, plus now an aditional path element for the project root dir itself.

I'm fairly convict D should have this "automatic global import/availability of symbol names" (what to call it?).



Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
This makes the module name declaration pretty much redundant, as well as the parent packages declaration (when given a common root dir for a set of source files), thus making the whole module statement redundant. I find this redundancy unnecessary and undesirable.
So, what possibilities then to this issue of redundancy in the naming of packages/modules? There are at first two options:

The current D way (no changes):
* Based upon directory+file structure AND in-file package+module declarations, thus having redundancy. (This is like Java)

Alternative:
* Based upon directory+file sctucture only: no need to specify package+module in-file, they are inferred.

I was originaly inclined to this second option, however, the introduction of automatic global import/availability of symbol names possibilitates a third option:

* Based upon in-file declarations only, the file pathnames do not matter at all. This is the C# way (mostly!). In D we would have the compiler search the first statement of all project files, which would be the module definition, to create the table of packages+modules.

Honestly, on this issue I'm not totally sure what would be best (if any is), but now I'm marginally inclined torwards the third option.

-- 
Bruno Medeiros
Computer Science/Engineering student

Bruno Medeiros wrote:
> First: more often than not, I like to access a symbol using its "fully qualified name" (what to call it?), like this:
> package1.module1.func(module2.var1);
> 
> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
I see your point, but rather than your suggested changes, I'd rather some decorator for the existant 'import' statement, or maybe a companion statement that behaves as you wish.

> Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
Actually this isn't precisely true.  For example, say I have a given package structure:
# lib/
#   ver1/
#     foo/
#       stuff.d
#   ver2/
#     foo/
#       stuff.d

And say I expect this program to be compiled with one of "-I./lib/ver1/" or "-I./lib/ver2/" on the command line.  Then within the program one would use "import foo.stuff;"... Now, say one of the "stuff" modules is for win32 and the other for linux. They're respective module declerations might then be:
# // ver1
# module foo.win32Stuff;

# // ver2
# module foo.linuxStuff;

Its entirely do-able.  Its also useful for a project that /will/ be importing modules with  same or similar file names from different places in the package hierarchy.

Its also worth noting that the module decleration is /optional/.  So if you don't want to use it, then you don't use it.  It defaults to the filename.  (Although, again, it can be useful for casing the module name while keeping the filename lo-cased for filesystem compatabilities.)

-- Chris Sauls

Chris Sauls schrieb:
> Bruno Medeiros wrote:
> 
>> First: more often than not, I like to access a symbol using its "fully
>> qualified name" (what to call it?), like this:
>> package1.module1.func(module2.var1);
>>
>> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
> 
> I see your point, but rather than your suggested changes, I'd rather some decorator for the existant 'import' statement, or maybe a companion statement that behaves as you wish.

Something along the lines of:

pragam(FQN_ONLY_EXCEPT_FOR_THE_CURRENT_MODULE);

would be interresting.

Granted the usefullnes depends on your coding style.


Thomas

Chris Sauls wrote:
> Bruno Medeiros wrote:
>> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
> 
> I see your point, but rather than your suggested changes, I'd rather some decorator for the existant 'import' statement, or maybe a companion statement that behaves as you wish.
> 

Yes, in the interests of compatibility, it would be best to do that, or use a different keyword ("simport" or whatever). Altough this is only second-best to having automatic FQN imports.

>> Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
> 
> Actually this isn't precisely true.  For example, say I have a given package structure:
> # lib/
> #   ver1/
> #     foo/
> #       stuff.d
> #   ver2/
> #     foo/
> #       stuff.d
> 
> And say I expect this program to be compiled with one of "-I./lib/ver1/" or "-I./lib/ver2/" on the command line.  Then within the program one would use "import foo.stuff;"... Now, say one of the "stuff" modules is for win32 and the other for linux. They're respective module declerations might then be:
> # // ver1
> # module foo.win32Stuff;
> 
> # // ver2
> # module foo.linuxStuff;
> 
> Its entirely do-able.  Its also useful for a project that /will/ be importing modules with  same or similar file names from different places in the package hierarchy.
> 
No, it is not do-able (have you actually tried it?). If you import a module ("import foo.stuff;") that is defined  in-file with a different module name ("module foo.win32Stuff;" or "module foo.linuxStuff;") You will get the following error:

file.d(4): module foo.win32stuff is in multiple packages foo.win32stuff

Which, BTW, I think now, is a somewhat incorrect compiler error message: it should state the two names by which the same module was refered to ( foo.stuff and foo.win32stuff).

-- 
Bruno Medeiros
Computer Science/Engineering student

Bruno Medeiros wrote:
> Chris Sauls wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
>>
>>
>> I see your point, but rather than your suggested changes, I'd rather some decorator for the existant 'import' statement, or maybe a companion statement that behaves as you wish.
>>
> 
> Yes, in the interests of compatibility, it would be best to do that, or use a different keyword ("simport" or whatever). Altough this is only second-best to having automatic FQN imports.

Maybe something like:
#  import foo; // this does what we already know
#  using  bar; // this requires fqn's

Only it might confuse people coming from environments where 'using' does what our 'import' does... but so be it.

>>> Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
>>
>>
>> Actually this isn't precisely true.  For example, say I have a given package structure:
>> # lib/
>> #   ver1/
>> #     foo/
>> #       stuff.d
>> #   ver2/
>> #     foo/
>> #       stuff.d
>>
>> And say I expect this program to be compiled with one of "-I./lib/ver1/" or "-I./lib/ver2/" on the command line.  Then within the program one would use "import foo.stuff;"... Now, say one of the "stuff" modules is for win32 and the other for linux. They're respective module declerations might then be:
>> # // ver1
>> # module foo.win32Stuff;
>>
>> # // ver2
>> # module foo.linuxStuff;
>>
>> Its entirely do-able.  Its also useful for a project that /will/ be importing modules with  same or similar file names from different places in the package hierarchy.
>>
> No, it is not do-able (have you actually tried it?). If you import a module ("import foo.stuff;") that is defined  in-file with a different module name ("module foo.win32Stuff;" or "module foo.linuxStuff;") You will get the following error:
> 
> file.d(4): module foo.win32stuff is in multiple packages foo.win32stuff
> 
> Which, BTW, I think now, is a somewhat incorrect compiler error message: it should state the two names by which the same module was refered to ( foo.stuff and foo.win32stuff).
> 

Hmm... I did just try it, and you're right.  To me it seems either a bug or a misfeature, and if the module name really is supposed to be the same as the file name, then its almost useless, other than for declaring package-hierarchies.  (And maybe for documentation if the new proposal for that flies, which I hope it does.)

-- Chris Sauls

There are some things in D I find less-than-ideal, but while on those issues I do agree my opinion (and other's) lies on a somewhat subjective realm, in this particular aspect I'm pretty sure D needs rethinking. And getting generalized indifference (got no comments) towards a change proposal is not a good sign :/ (people not caring?)
So could I please get an official comment (i.e. Walter's) on this issue, (even if just a one-liner)? This is too important to give up.

Bruno Medeiros wrote:
> Concerning in D the whole aspect of imports, packages, modules and symbol name scopes, etc.(what to call this whole thing?) there are some things I find ill-conceived, so much that I think this aspect of D is in need of some rethinking.
> 
> 
> First: more often than not, I like to access a symbol using its "fully qualified name" (what to call it?), like this:
> package1.module1.func(module2.var1);
> 
> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.
> The first alternative that came to mind was to change import so that it would do so: make the symbols accessible only by FQN, and then we would have a /using/ statement, same as C++, that would bring packages or modules to the local scope (and that would replace the /with/ statement).
> 
> But then I realized, why do we then even need the imports at all? Why not automatically import all available modules (into FQN scope), and just use the /using/ keyword when we want to bring external scopes closer? (Are we still thinking C++ legacy-like here?...) It's the simple logical conclusion. Simple and in fact nothing new, as both Java and C# do it this way, which further assures me this is a better behaviour.
> 
> This feature requires an import path, i.e. a list of directories where to search and import the symbol names (in Java this is the CLASSPATH). In D this would be the already existant path defined by the -I command-line options, plus now an aditional path element for the project root dir itself.
> 
> I'm fairly convict D should have this "automatic global import/availability of symbol names" (what to call it?).
> 
> 
> 
> Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
> This makes the module name declaration pretty much redundant, as well as the parent packages declaration (when given a common root dir for a set of source files), thus making the whole module statement redundant. I find this redundancy unnecessary and undesirable.
> So, what possibilities then to this issue of redundancy in the naming of packages/modules? There are at first two options:
> 
> The current D way (no changes):
> * Based upon directory+file structure AND in-file package+module declarations, thus having redundancy. (This is like Java)
> 
> Alternative:
> * Based upon directory+file sctucture only: no need to specify package+module in-file, they are inferred.
> 
> I was originaly inclined to this second option, however, the introduction of automatic global import/availability of symbol names possibilitates a third option:
> 
> * Based upon in-file declarations only, the file pathnames do not matter at all. This is the C# way (mostly!). In D we would have the compiler search the first statement of all project files, which would be the module definition, to create the table of packages+modules.
> 
> Honestly, on this issue I'm not totally sure what would be best (if any is), but now I'm marginally inclined torwards the third option.
> 


-- 
Bruno Medeiros
Computer Science/Engineering student

On Tue, 30 Aug 2005 23:44:43 +0000, Bruno Medeiros wrote:

> There are some things in D I find less-than-ideal, but while on those issues I do agree my opinion (and other's) lies on a somewhat subjective realm, in this particular aspect I'm pretty sure D needs rethinking. And getting generalized indifference (got no comments) towards a change proposal is not a good sign :/ (people not caring?)

I haven't responded because I'm not too sure about what the issues are. I don't really understand what you are asking for.

> So could I please get an official comment (i.e. Walter's) on this issue, (even if just a one-liner)? This is too important to give up.
> 
> Bruno Medeiros wrote:
>> Concerning in D the whole aspect of imports, packages, modules and symbol name scopes, etc.(what to call this whole thing?) there are some things I find ill-conceived, so much that I think this aspect of D is in need of some rethinking.
>> 
>> First: more often than not, I like to access a symbol using its "fully
>> qualified name" (what to call it?), like this:
>> package1.module1.func(module2.var1);
>> 
>> Currently, if I want to do this I have to import the respective modules, which unfortunately also brings the imported modules scope to the local module scope, which I do not want. I want to keep the local scope clean and access these imported modules only by its FQN.

I haven't had a problem with this. What problems is this behaviour giving you?

>> The first alternative that came to mind was to change import so that it would do so: make the symbols accessible only by FQN, and then we would have a /using/ statement, same as C++, that would bring packages or modules to the local scope (and that would replace the /with/ statement).
>> 
>> But then I realized, why do we then even need the imports at all? Why not automatically import all available modules (into FQN scope), and just use the /using/ keyword when we want to bring external scopes closer? (Are we still thinking C++ legacy-like here?...) It's the simple logical conclusion. Simple and in fact nothing new, as both Java and C# do it this way, which further assures me this is a better behaviour.
>> 
>> This feature requires an import path, i.e. a list of directories where to search and import the symbol names (in Java this is the CLASSPATH). In D this would be the already existant path defined by the -I command-line options, plus now an aditional path element for the project root dir itself.
>> 
>> I'm fairly convict D should have this "automatic global import/availability of symbol names" (what to call it?).

Are you saying that if somewhere in my code I have a full qualified name for an external item, that the D compiler should assume that I had meant to also code the import statement for that module? If so, should it assume a private or public import?

For example:

     result = std.string.strip(theField);

would cause DMD to assume that I had also coded ...

  private import std.string;

>> Second: the module statement. The module statement specifies the name of
>> the module, and the hierarchy of parent packages. The module name
>> however must match the file name, and the packages must match the
>> underlying directory structure, otherwise the source file will be
>> unusable (un-importable actually).
>> This makes the module name declaration pretty much redundant, as well as
>> the parent packages declaration (when given a common root dir for a set
>> of source files), thus making the whole module statement redundant. I
>> find this redundancy unnecessary and undesirable.

I agree that the module statement is basically useless and an inconvenience. The only thing is seems to do is enforce which package a module is supposed to be in.

>> So, what possibilities then to this issue of redundancy in the naming of packages/modules? There are at first two options:
>> 
>> The current D way (no changes):
>> * Based upon directory+file structure AND in-file package+module
>> declarations, thus having redundancy. (This is like Java)
>> 
>> Alternative:
>> * Based upon directory+file sctucture only: no need to specify
>> package+module in-file, they are inferred.
>>
>> I was originaly inclined to this second option, however, the introduction of automatic global import/availability of symbol names possibilitates a third option:
>> 
>> * Based upon in-file declarations only, the file pathnames do not matter at all. This is the C# way (mostly!). In D we would have the compiler search the first statement of all project files, which would be the module definition, to create the table of packages+modules.

What's a "project file"? Do just mean a source code file? How would DMD find all project files, that is, all files that belong to a project? One can't assume that all files in a specific directory belong to the same application, and some projects generate more than one application program. So I guess I'm not sure what you are asking for here. Can you give examples?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
31/08/2005 9:48:34 AM

Derek Parnell wrote:
> On Tue, 30 Aug 2005 23:44:43 +0000, Bruno Medeiros wrote:
> 
> I haven't responded because I'm not too sure about what the issues are. I
> don't really understand what you are asking for.
> 
Hum.. I was under the impression that the post was clear. I will clarify, but before that let know this: are you familiar with (as in having some experience with) Java or C#?


-- 
Bruno Medeiros
Computer Science/Engineering student

On Wed, 31 Aug 2005 00:56:32 +0000, Bruno Medeiros wrote:

> Derek Parnell wrote:
>> On Tue, 30 Aug 2005 23:44:43 +0000, Bruno Medeiros wrote:
>> 
>> I haven't responded because I'm not too sure about what the issues are. I don't really understand what you are asking for.
>> 
> Hum.. I was under the impression that the post was clear. I will clarify, but before that let know this: are you familiar with (as in having some experience with) Java or C#?

Just a little under 1% ;-)

Could you use plain English instead?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
31/08/2005 11:04:30 AM

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:delf3c$2p1d$1@digitaldaemon.com...
> Concerning in D the whole aspect of imports, packages, modules and symbol name scopes, etc.(what to call this whole thing?) there are some things I find ill-conceived, so much that I think this aspect of D is in need of some rethinking.
[snip]
> But then I realized, why do we then even need the imports at all?

One benefit is that it becomes much easier to figure out the dependencies between modules. One only has to look at import statements to decide if module foo depends on module bar. Without import statements one has to not only find all "bar." strings one also has to make sure bar isn't a local variable that's a structure or object where "bar." doesn't refer to the module bar at all.

> Second: the module statement. The module statement specifies the name of the module, and the hierarchy of parent packages. The module name however must match the file name, and the packages must match the underlying directory structure, otherwise the source file will be unusable (un-importable actually).
[snip]

There are two points to consider:
1) like Java D source codes doesn't have to be stored in a file system with
directories etc. See
http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.2
2) by storing the package and module name in the file(s) the entire
hierarchy can be recreated from the source code. That is, the contents of
the source code defines the program completely, not the source
code+directory structure.