www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - is there a way to enforce module 'namespace' semantics?

reply clayasaurus <clayasaurus gmail.com> writes:
Hi,

Say I have module foo, and it has funtion bar, like this

------foo.d---------------
module foo;

void bar()
{
}
--------------------------

Now, I'm writing a library and I don't want the user of the library to 
be able to call bar by itself, like this

------main.d--------------
import foo;

bar(); // nose
--------------------------

Instead, I want to make it so the only way the user can call bar is like 
this

------main.d--------------
import foo;

foo.bar(); // yes
--------------------------

Is there a way I can enforce the functions inside of the module? Maybe 
like this?

------foo.d---------------
module foo;

enforce // enforces module 'namespace'
{
   void bar()
   {
   }
}
--------------------------

The reason I want to enforce the module 'namespace' is because I'm using 
modules as a replacement for a global class. I have multiple modules 
with similar function names, and as the library writer, I don't want my 
users to just call 'bar()', because it is not how I want the module to 
be used and the compiler will complain if they import another module 
with the same function name 'bar()'

Is there a good solution to this problem? Or should there be some way to 
enforce module 'namespace' within D?

Thanks.
  - Clay
Mar 20 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
clayasaurus wrote:

 Instead, I want to make it so the only way the user can call bar is like 
 this
 ------main.d--------------
 import foo;
 
 foo.bar(); // yes
 --------------------------


A darn good question: I'd very much like this myself.  One possible 
(albeit hackish) solution I thought of off the top of my head would be 
to use static members of an abstract class... ie:














Granted it probably provides feeding ground for cute errors from missing 
capitalization, but it should work.  Maybe I'll test it later.

-- Grant
Mar 20 2005
parent clayasaurus <clayasaurus gmail.com> writes:
Chris Sauls wrote:

 clayasaurus wrote:
 

 Instead, I want to make it so the only way the user can call bar is 
 like this
 ------main.d--------------
 import foo;

 foo.bar(); // yes
 --------------------------


 
 
 A darn good question: I'd very much like this myself.  One possible 
 (albeit hackish) solution I thought of off the top of my head would be 
 to use static members of an abstract class... ie:
 





 






 
 Granted it probably provides feeding ground for cute errors from missing 
 capitalization, but it should work.  Maybe I'll test it later.
 
 -- Grant


That may be a decent alternative, but it doesn't cut it for me, since it 
is using pseudo-module namespace, and you can call weird things like...

foo.Foo.bar() // i think

It would be simpler to just let the compiler bite the user when they try 
to do this

----------------------------
import foo1; // has bar()
import foo2; // has bar()

bar();
----------------------------

but it would be more consistent to be able to enforce the 'namespace', 
so this kind of thing can never happen (it does when programmers get 
shortsighted/lazy)


Thanks for the reply : )
- Clay
Mar 20 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 The reason I want to enforce the module 'namespace' is because I'm using 
 modules as a replacement for a global class. I have multiple modules with 
 similar function names, and as the library writer, I don't want my users 
 to just call 'bar()', because it is not how I want the module to be used


why not? D is designed to be used that way. Can you give more details about 
the API? Personally I wouldn't fight the standard D style but one is free to 
make whatever API one wants, I suppose. If the standard approach results in 
errors or painful usage then I suggest posting examples so that Walter can 
try to find a nice solution.


 and the compiler will complain if they import another module with the same 
 function name 'bar()'


It should only complain when they try to use it. When that happens they will 
have to use the foo.bar or an alias to fix the conflict.

You might be seeing import conflicts because of public imports, too. This, 
actually, is one reason why private imports are better than public ones 
because it can be nasty to track down conflicts when you nest several public 
imports and somewhere along the chain a conflict happens. Keeping everything 
private prevents that from happening.

-Ben
Mar 20 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Ben Hinkle wrote:

The reason I want to enforce the module 'namespace' is because I'm using 
modules as a replacement for a global class. I have multiple modules with 
similar function names, and as the library writer, I don't want my users 
to just call 'bar()', because it is not how I want the module to be used


 
 
 why not? D is designed to be used that way. Can you give more details about 
 the API? Personally I wouldn't fight the standard D style but one is free to 
 make whatever API one wants, I suppose. If the standard approach results in 
 errors or painful usage then I suggest posting examples so that Walter can 
 try to find a nice solution.


I would rather use a 'module global' instead of a 'class global', 
because with classes you have to 'new' it, and you have to give it a 
name, which would probably be something like 'gClass'. With a 'module 
global', the name is the module name, and I don't have to 'new' it.

These globals are ok for me, because they are there for the entire 
length of the program, and everything needs easy access to them.

Also, with module global, there is no need for declaration, as you just 
use 'import module' : ) I see this as a nice solution, and easy for the 
user of your program to use, for instance

----------------------------------
import input;

input.open()
input.process()

if (input.keyDown('a'))
    writefln("a key is down")
----------------------------------

versus

----------------------------------
import input;

gInput = new Input();

gInput.open();
gInput.process()

if (gInput.keyDown("a"))
    writefln("a key is down");
----------------------------------

Also, I have a module named window, which holds window width, size, etc, 
and that has similar function names so the code is familiar.

I am not asking that all D modules require this, I am just asking for a 
keyword (or something else?) to enforce the module namespace, or asking 
if someone can think of a better solution (I know I am not a master 
programmer)

What I have, a snippet from my code, is something like this...

---- input.d --------------
module input;

private
{
   // vars
}

public
{
   // funcs
   open()
   close()
}
---------------------------

I have a very similar

------- window.d ----------
module window;

private
{
   // vars
}

public
{
   open()
   close()
}
--------------------------

Now, with my program, window and input and guarenteed to be used 
together, and if one calls

open(); // depending on the cirsumstance, will either err or be 'ok',
         // but for consistency, I would rather force the code to be
         // input.open() or window.open(), so the programmer knows what
         // is happening and so, depending on what you import, you don't
         // all of a sudden get the compiler complaining to you

Maybe I'm making a big deal out of nothing, and I'll just let an 
ignorant programmer write weird code that could mean different things 
depending on what I import.



 
 

and the compiler will complain if they import another module with the same 
function name 'bar()'


 
 
 It should only complain when they try to use it. When that happens they will 
 have to use the foo.bar or an alias to fix the conflict.


if i can choose to have the compiler complain about foo in the first 
place, no worries :) as they'll have to use foo.bar.

also, they will not want to use an alias, because there is no better 
name they can alias too :)


 
 You might be seeing import conflicts because of public imports, too. This, 
 actually, is one reason why private imports are better than public ones 
 because it can be nasty to track down conflicts when you nest several public 
 imports and somewhere along the chain a conflict happens. Keeping everything 
 private prevents that from happening.


It might be nice for D to force either 'public' or 'private' on all 
things within the module, and not default everything to 'public' or 
'priavte'

I know, at first, I didn't understand that D defaulted all module access 
to public. And, I don't think it hurts productivity to force either 
public or private, rather it makes the programmer think about what they 
really want to be shared within a module, potentially avoiding hard to 
track down future module conflicts within large programs.

Anyway, what it boils down to for me is that if i have module

module foo; // has bar() in it
module dance; // has bar() in it

bar(); // the compiler will complain, no?

Bar, is a public function, I want it to be public, I need it to be 
public. I know what I can hide and what I can't. :)

I just think it would be nice if I could make the compiler complain in 
the first place, so my library can not be abused.


 
 -Ben
Mar 20 2005
parent reply Lukas Pinkowski <Lukas.Pinkowski web.de> writes:
clayasaurus wrote:


 Ben Hinkle wrote:

The reason I want to enforce the module 'namespace' is because I'm using
modules as a replacement for a global class. I have multiple modules with
similar function names, and as the library writer, I don't want my users
to just call 'bar()', because it is not how I want the module to be used


 
 
 why not? D is designed to be used that way. Can you give more details
 about the API? Personally I wouldn't fight the standard D style but one
 is free to make whatever API one wants, I suppose. If the standard
 approach results in errors or painful usage then I suggest posting
 examples so that Walter can try to find a nice solution.


 
 I would rather use a 'module global' instead of a 'class global',
 because with classes you have to 'new' it, and you have to give it a
 name, which would probably be something like 'gClass'. With a 'module
 global', the name is the module name, and I don't have to 'new' it.


I use classes with static methods and properties, thus having something like
a namespace. You don't have to 'new' a class to use its static methods and
members and you are forced to use MyClass.method() instead of just method()
like in modules.

ie.

module input;
class Input
{
  static
  {
    void open() { bla }
    void process() { bla }
    ...
  }
}

and

import input;

Input.open();
Input.process();

...
Mar 20 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 I use classes with static methods and properties, thus having something 
 like
 a namespace. You don't have to 'new' a class to use its static methods and
 members and you are forced to use MyClass.method() instead of just 
 method()
 like in modules.

 ie.

 module input;
 class Input
 {
  static
  {
    void open() { bla }
    void process() { bla }
    ...
  }
 }

 and

 import input;

 Input.open();
 Input.process();

 ...


Maybe it's just me but I don't want to see this become common in D. The 
whole point of the module rules is to free users from having to type Input. 
or whatever. Please don't force me as a user of your library to work in Java 
style where dummy classes wrap top-level functions. If you (meaning a 
library author) wants to always include the module name in your code because 
you think it looks nice then feel free to do that (it is legal D so it isn't 
a problem). But please let's keep D libraries free from the hacks that other 
languages need. The module rules in D are flexible enough to keep everyone 
happy. If they aren't then we need to alert Walter so that he can fix it up.
Mar 20 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Ben Hinkle wrote:

I use classes with static methods and properties, thus having something 
like
a namespace. You don't have to 'new' a class to use its static methods and
members and you are forced to use MyClass.method() instead of just 
method()
like in modules.

ie.

module input;
class Input
{
 static
 {
   void open() { bla }
   void process() { bla }
   ...
 }
}

and

import input;

Input.open();
Input.process();

...


 
 
 Maybe it's just me but I don't want to see this become common in D. The 
 whole point of the module rules is to free users from having to type Input. 
 or whatever.


When you have two modules with the same functions, you are forced to 
type input anyway, the compiler will complain.

In my lib, you are guarenteed to have two modules with the same function 
names, out of design.

What happens when it goes wrong is that it you get a weird error 
message, like "foo.d(3): function foo.fooo conflicts with bar.fooo at 
bar.d(3)," that doesn't give you the name of the source file where the 
actual conflict occurs (in this case main.d), and it is a bit hard to 
track down in a large program.

I thought it would be better to enforce module namespace so these errors 
do not happen, and if you forget to do it then the compiler can tell you 
the line of code it goes wrong on.


 Please don't force me as a user of your library to work in Java 
 style where dummy classes wrap top-level functions. If you (meaning a 
 library author) wants to always include the module name in your code because 
 you think it looks nice then feel free to do that (it is legal D so it isn't 
 a problem). But please let's keep D libraries free from the hacks that other 
 languages need. The module rules in D are flexible enough to keep everyone 
 happy. If they aren't then we need to alert Walter so that he can fix it up. 
 


I've decided i'm not going to use static classes or whatever (though 
neat trick!)

I'll just let the compiler bite when it feels it is time :-) And then 
they can have fun tracking it down, without DMD telling you the line or 
source where the conflict occurs. fun.
Mar 20 2005
next sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
clayasaurus wrote:

 
 I've decided i'm not going to use static classes or whatever (though 
 neat trick!)
 
 I'll just let the compiler bite when it feels it is time :-) And then 
 they can have fun tracking it down, without DMD telling you the line or 
 source where the conflict occurs. fun.
 
 


I'm with Ben here. What if in one of your modules you forget your 
proposed "enforce" attribute?

module a;
enforce:
void foo() {}

module b;
//oops, forgot enforce
void foo() {}

module usercode;
void bar()
{
     foo();     // user made a mistake: he meant a.foo
}

The compiler would not complain about it and the user would get a wrong 
result.

Again, I also prefer the flexibility that D gives right now.

_______________________
Carlos Santander Bernal
Mar 20 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
clayasaurus wrote:
...


 When you have two modules with the same functions, you are forced to 
 type input anyway, the compiler will complain.
 
 In my lib, you are guarenteed to have two modules with the same function 
 names, out of design.
 
 What happens when it goes wrong is that it you get a weird error 
 message, like "foo.d(3): function foo.fooo conflicts with bar.fooo at 
 bar.d(3)," that doesn't give you the name of the source file where the 
 actual conflict occurs (in this case main.d), and it is a bit hard to 
 track down in a large program.


I think this part of the issue can best be solved by a better error 
message. Maybe if we mention these substandard error messages enough 
times, Walter will have a chance to fix them. ;)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Mar 20 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 20 Mar 2005 21:48:17 -0600, J C Calvarese wrote:


 clayasaurus wrote:
 ...
 

 When you have two modules with the same functions, you are forced to 
 type input anyway, the compiler will complain.
 
 In my lib, you are guarenteed to have two modules with the same function 
 names, out of design.
 
 What happens when it goes wrong is that it you get a weird error 
 message, like "foo.d(3): function foo.fooo conflicts with bar.fooo at 
 bar.d(3)," that doesn't give you the name of the source file where the 
 actual conflict occurs (in this case main.d), and it is a bit hard to 
 track down in a large program.


 
 I think this part of the issue can best be solved by a better error 
 message. Maybe if we mention these substandard error messages enough 
 times, Walter will have a chance to fix them. ;)


I suspect that you are very correct here. In general, I think that Walter
needs to make a determined effort to systematically go through the compiler
and standardize all the error messages. They should at the very least
identify the file name and line number that *triggered* the error, and the
text of the message needs to be in plain language rather than
compiler-speak (i.e. Minimize the computer science jargon).

-- 
Derek
Melbourne, Australia
21/03/2005 2:52:15 PM
Mar 20 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
Derek Parnell wrote:

 On Sun, 20 Mar 2005 21:48:17 -0600, J C Calvarese wrote:


...

What happens when it goes wrong is that it you get a weird error 
message, like "foo.d(3): function foo.fooo conflicts with bar.fooo at 
bar.d(3)," that doesn't give you the name of the source file where the 
actual conflict occurs (in this case main.d), and it is a bit hard to 
track down in a large program.


I think this part of the issue can best be solved by a better error 
message. Maybe if we mention these substandard error messages enough 
times, Walter will have a chance to fix them. ;)


 
 
 I suspect that you are very correct here. In general, I think that Walter
 needs to make a determined effort to systematically go through the compiler
 and standardize all the error messages. They should at the very least
 identify the file name and line number that *triggered* the error, and the
 text of the message needs to be in plain language rather than
 compiler-speak (i.e. Minimize the computer science jargon).


Well, there always going to have to be some computer science jargon, but 
the message should at least provide all of the relevant line numbers. 
And I think Walter is already responsive to these criticisms, one man 
can only find and fix them so fast. I wonder how much we could help by 
pointing him to a particular string in the front-end. Hmmm...

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
Mar 20 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 20 Mar 2005 22:21:32 -0600, J C Calvarese <jcc7 cox.net> wrote:

 Derek Parnell wrote:

 On Sun, 20 Mar 2005 21:48:17 -0600, J C Calvarese wrote:


 ...

 What happens when it goes wrong is that it you get a weird error  
 message, like "foo.d(3): function foo.fooo conflicts with bar.fooo at  
 bar.d(3)," that doesn't give you the name of the source file where  
 the actual conflict occurs (in this case main.d), and it is a bit  
 hard to track down in a large program.


 I think this part of the issue can best be solved by a better error  
 message. Maybe if we mention these substandard error messages enough  
 times, Walter will have a chance to fix them. ;)


   I suspect that you are very correct here. In general, I think that  
 Walter
 needs to make a determined effort to systematically go through the  
 compiler
 and standardize all the error messages. They should at the very least
 identify the file name and line number that *triggered* the error, and  
 the
 text of the message needs to be in plain language rather than
 compiler-speak (i.e. Minimize the computer science jargon).


 Well, there always going to have to be some computer science jargon, but  
 the message should at least provide all of the relevant line numbers.  
 And I think Walter is already responsive to these criticisms, one man  
 can only find and fix them so fast. I wonder how much we could help by  
 pointing him to a particular string in the front-end. Hmmm...


I had a very brief look at the front end code (so I may be way off base  
here) but I noticed the error function simply gets passed a string, which  
it then prints. What if Walter changes that to take a file, line and  
error. The function could then print in a set format, the calling code  
would all error highlighting all the calls which now require file/line  
information.

Regan
Mar 20 2005
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I think you may have something like:

implementation_module.d - all your real stuff is here,
including definition of functionCall().

module.d:
// Proxy
struct module{
	import implementation_module;
}
// end of module.d

test.d:
import module;

void main(){
	// this should work:
	module.functionCall();
	// this must fail:
	//~ functionCall();
}
// end of module.d

However, if you really have collision on function names, it might be a 
hint that you might want to bring some class encapsulation into the 
game, or solve the issue otherwise. You should never give functions the 
same name, unless they also do exactly the same - perhaps, on different 
types. However, if they do the same, you have 2 possibilities: either 
drop all functions into the same namespace, or you can find a place in a 
class hierarchy, making full-scale methods out of them.

To drop all the functions into the same namespace, you need not define 
them in the same module. Instead, say ambiguousFunction() is defined in 
module1, module2 and module3, using different types as argument. Then in 
  a new module you may do:

module common;

private import module1, module2, module3;

alias module1.ambiguousFunction ambiguousFunction;
alias module2.ambiguousFunction ambiguousFunction;
alias module3.ambiguousFunction ambiguousFunction;

Now when you import them all through module "common" they will obey to 
type overloading correctly.

-eye
Mar 21 2005