## D - Collision problems (ugly, compicated and serious)

• Helmut Leitner (75/75) Apr 16 2003 Theoretically there should be no collision problems in D,
• Walter (2/2) Apr 16 2003 I don't quite follow. Can you post a simple example of such an unresolva...
• Sean L. Palmer (6/81) Apr 16 2003 It seems to me that importing pulls in too much stuff anyway. Aren't a
• Matthew Wilson (5/8) Apr 16 2003 Agreed, although I am open to the idea that there are compelling concept...
• Helmut Leitner (7/7) Apr 18 2003 This may have been a false alarm. While preparing simplified
Helmut Leitner <leitner hls.via.at> writes:
```Theoretically there should be no collision problems in D,
but there are. At least I have them and don't know yet how to
handle them.

The typical situation is, that identical functions are declared
(as interfaces) or defined in different modules, lets call them
moda and modb and the function fcoll.

No problem, you can either import just one of the modules
(A)
import moda;
fcoll();

or qualify the call in your source:
(B)
import moda;
import modb;
moda.fcoll();

No problem? Not yet. But both solutions will lead into problems
if you put your code into libraries to reuse them, lets call
the library module that contains the code libmod.

So you want to do
import libmod;
libfunc();

or
import moda;
import libmod;
libfunc();
or
import modb;
import libmod;
libfunc();
or
import moda;
import modb;
import libmod;
libfunc();

So in a way, the definitions of moda and modb have to live together.
Its inevitable that they are brought together, whether you want it
or not.

The problem is, that if you use the libmod you get collision but
don't have the means to resolve it!!!!

That's problem (1).

Problem (2) is that there are unresolvable collision problems when
only the function name collides, but also types that are used by
the colliding functions.

This is currently the case, even if the definitions within moda and
modb are identical typedefs or structs.

This whole problem will hit you, when you bring phobos.windows
(with its partial Win32 deklarations) and pavel.windows together.
They have idential definitions whose collisions can't be resolved.
At least I can't.

Even if they were joined, the problem would not be solved, because
we can never hope that such an interface definition is exact and
complete. There will always be little enhanements and corrections
necessary in a project, which will again raise the problem.

A facet of the problem is that you don't see a collision until
you use an colliding definition. That's in a way nice but also
desastrous, because you can not easily be sure to deliver code
that can be used without collisions.

Does anyone see a solution?

At the moment I think that D should assume while importing modules
that in case of a collision a definition within the module is
assumed as qualified by default.

So if moda says:

typedef int BOOL;
func (BOOL);

and modb says:

typedef int BOOL;
func (BOOL);

this should mean

moda.func(moda.BOOL);
modb.func(modb.BOOL);

implicitely.

But I don't think that this alone would be sufficient.

--
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
```
Apr 16 2003
"Walter" <walter digitalmars.com> writes:
```I don't quite follow. Can you post a simple example of such an unresolvable
collision?
```
Apr 16 2003
"Sean L. Palmer" <palmer.sean verizon.net> writes:
```It seems to me that importing pulls in too much stuff anyway.  Aren't a
module's imports also exported by default?  This seems wrong.

It seems clear to me that you have identified a problem.

Sean

"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3E9D250A.C0DB58F7 hls.via.at...
Theoretically there should be no collision problems in D,
but there are. At least I have them and don't know yet how to
handle them.

The typical situation is, that identical functions are declared
(as interfaces) or defined in different modules, lets call them
moda and modb and the function fcoll.

No problem, you can either import just one of the modules
(A)
import moda;
fcoll();

or qualify the call in your source:
(B)
import moda;
import modb;
moda.fcoll();

No problem? Not yet. But both solutions will lead into problems
if you put your code into libraries to reuse them, lets call
the library module that contains the code libmod.

So you want to do
import libmod;
libfunc();

or
import moda;
import libmod;
libfunc();
or
import modb;
import libmod;
libfunc();
or
import moda;
import modb;
import libmod;
libfunc();

So in a way, the definitions of moda and modb have to live together.
Its inevitable that they are brought together, whether you want it
or not.

The problem is, that if you use the libmod you get collision but
don't have the means to resolve it!!!!

That's problem (1).

Problem (2) is that there are unresolvable collision problems when
only the function name collides, but also types that are used by
the colliding functions.

This is currently the case, even if the definitions within moda and
modb are identical typedefs or structs.

This whole problem will hit you, when you bring phobos.windows
(with its partial Win32 deklarations) and pavel.windows together.
They have idential definitions whose collisions can't be resolved.
At least I can't.

Even if they were joined, the problem would not be solved, because
we can never hope that such an interface definition is exact and
complete. There will always be little enhanements and corrections
necessary in a project, which will again raise the problem.

A facet of the problem is that you don't see a collision until
you use an colliding definition. That's in a way nice but also
desastrous, because you can not easily be sure to deliver code
that can be used without collisions.

Does anyone see a solution?

At the moment I think that D should assume while importing modules
that in case of a collision a definition within the module is
assumed as qualified by default.

So if moda says:

typedef int BOOL;
func (BOOL);

and modb says:

typedef int BOOL;
func (BOOL);

this should mean

moda.func(moda.BOOL);
modb.func(modb.BOOL);

implicitely.

But I don't think that this alone would be sufficient.

--
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

```
Apr 16 2003
"Matthew Wilson" <matthew stlsoft.org> writes:
```"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b7leam\$64\$1 digitaldaemon.com...
It seems to me that importing pulls in too much stuff anyway.  Aren't a
module's imports also exported by default?  This seems wrong.

Agreed, although I am open to the idea that there are compelling conceptual
reasons why it must be so. But it does feel wrong

It seems clear to me that you have identified a problem.

Indeed
```
Apr 16 2003
Helmut Leitner <helmut.leitner chello.at> writes:
```This may have been a false alarm. While preparing simplified
examples I found that qualifying all qualified datatypes
and structures solved my problems (that's a PITA for the
Win32 API declarations but no real problem).

--
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
```
Apr 18 2003