View mode: basic / threaded / horizontal-split · Log in · Help
March 21, 2005
Re: is there a way to enforce module 'namespace' semantics?
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
March 21, 2005
Re: is there a way to enforce module 'namespace' semantics?
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/
March 21, 2005
Re: is there a way to enforce module 'namespace' semantics?
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
March 21, 2005
Re: is there a way to enforce module 'namespace' semantics?
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home