Hello Walter,

> bearophile wrote:
> 
>> Walter Bright:
>> 
>> Thank you for your answer.
>> 
>>> The error is not a mismatched file name, which is perfectly
>>> legitimate in D.
>>> 
>> Do you mean that in D it is OK to have a file named "foo.d" with
>> inside it at the top written "module bar;" ?
>> 
> Yes.
> 
>> What's the rationale behind this? (I don't like this).
>> 
> The flexibility comes in handy now and then.
> 

For example, having foo_linux.d and foo_win.d both claiming to be foo.


-- 
... <IXOYE><

Walter Bright:
> The flexibility comes in handy now and then.

OK, I have never felt the need of such extra flexibility in my D programs, so I trust your judgement.

Every time a a semantic hole is left in a language (and this is a little hole), you have to pay a price, in terms for example of:
- less easy to understand error messages (the currently generated error message is not easy to understand and I think it's wrong, because in that program the four names are distinct, there is no duplication);
- less simplicity for the D newbies to learn the language, because to learn something faster you need a strict teacher;
- possible bugs caused by side effects of the semantic hole (because semantic holes often create semantic loopholes).

In Delphi the "main unit" of a program is denoted with for example, at the top: program Project1;

Bye,
bearophile

BCS:
> For example, having foo_linux.d and foo_win.d both claiming to be foo.

OK.
And I presume you don't want to use a single module with a mega version(linux) {...} else {...} inside.

Thank you,
bearophile

On 09/04/10 23:11, bearophile wrote:
> BCS:
>> For example, having foo_linux.d and foo_win.d both claiming to be foo.
>
> OK.
> And I presume you don't want to use a single module with a mega version(linux) {...} else {...} inside.
>
> Thank you,
> bearophile

No need for a huge module, or module names mismatching file names:
----
module foo;

version (linux) import foo_linux;
version (Windows) import foo_linux;
----
Sure it adds and extra file, it's a lot cleaner imo than having a huge module with both implementations or mismatching file/module names.

Hello Robert,

> No need for a huge module, or module names mismatching file names:
> ----
> module foo;
> version (linux) import foo_linux;
> version (Windows) import foo_win;
> ----
> Sure it adds and extra file, it's a lot cleaner imo than having a huge
> module with both implementations or mismatching file/module names.

I don't think that works in one case; where you are forced to use fully qualified name.

import foo;
import something.else;

bar(); // calls  something.else.bar;
foo.bar(); // IIRC this don't work

OTOH, you might be able to get around that with the following:

version (linux) { import foo_linux; alias foo_linux foo; }
version (Windows) { import foo_win; alias foo_win foo; }

(I haven't tested any of that because my systems are being shipped right now.)

-- 
... <IXOYE><

BCS:
> I don't think that works in one case; where you are forced to use fully qualified name.

You can probably use a "public import".

Bye,
bearophile

Hello bearophile,

> BCS:
> 
>> I don't think that works in one case; where you are forced to use
>> fully qualified name.
>> 
> You can probably use a "public import".
> 

IIRC, all that does is make anything that imports you, import that as well. It doesn't do anything to the names.

-- 
... <IXOYE><

BCS:
> IIRC, all that does is make anything that imports you, import that as well. It doesn't do anything to the names.

I meant to create a module named "foo" with inside:

module foo;
version (linux) public import foo_linux;
version (Windows) public import foo_win;

The module system has numerous holes (that Walter will need to take a look at, because three of them alone cover almost 10% of all bugzilla votes), so this is not going to work perfectly, but now if you import foo you have available all the names inside foo_linux and foo_win.

Bye,
bearophile

Hello bearophile,

> BCS:
> 
>> IIRC, all that does is make anything that imports you, import that as
>> well. It doesn't do anything to the names.
>> 
> I meant to create a module named "foo" with inside:
> 
> module foo;
> version (linux) public import foo_linux;
> version (Windows) public import foo_win;
> The module system has numerous holes (that Walter will need to take a
> look at, because three of them alone cover almost 10% of all bugzilla
> votes), so this is not going to work perfectly, but now if you import
> foo you have available all the names inside foo_linux and foo_win.

That's exactly what I thought you were suggesting.

The problem is that, IIRC and assuming foo_linux and foo_win both contain a bar, the the following still doesn't work:

foo.bar();

what works is:

foo_linux.bar();

or

foo_win.bar();

In the case that just bar() doesn't work (say there is another bar somewhere else), you're sunk.

-- 
... <IXOYE><

>>  What's the rationale behind this? (I don't like this).
>
> The flexibility comes in handy now and then.

but isn't that an abstract form of hijacking then?
or an sideeffect smelling like that?