www.digitalmars.com         C & C++   DMDScript  

D - Collision problems (ugly, compicated and serious)

reply 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
next sibling parent "Walter" <walter digitalmars.com> writes:
I don't quite follow. Can you post a simple example of such an unresolvable
collision?
Apr 16 2003
prev sibling next sibling parent reply "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
parent "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
prev sibling parent 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