March 21, 2005
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
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
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
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
1 2
Next ›   Last »