[m-rev.] [dotnet] diff: fix namespaces bugs.

Peter Ross peter.ross at miscrit.be
Fri Apr 20 21:31:44 AEST 2001


On Sat, Apr 14, 2001 at 02:38:43PM +1000, Fergus Henderson wrote:
> On 13-Apr-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > Branches: dotnet-foreign
> > 
> > compiler/mlds_to_il.m:
> > 	In the module foo.m, all the code is now placed into a type called
> > 	mercury_code in the namespace foo, rather then in they type foo and
> > 	no namespace.  This avoids problems where you cannot have a type and
> > 	namespace at the top level with the same name.                              
> There's a similar issue for the Java back-end, because Java doesn't
> allow a type and a namespace with the same name.
> Julien Fischer and I discussed that in some detail,
> and decided on a different solution:
> give the namespace a name starting with a lowercase letter
> and give the class a name starting with an uppercase letter.
> 
> This solution is nicer for interoperability, since it is more
> in line with the usual Java naming conventions.  I think the
> same would be true for the .NET back-end.
> 
While a reasonable solution, I believe it will have problems if we are
interacting with other code which doesn't obey this convention.

> What problems arise in .NET if you have a namespace and a class
> with the same name?
> 
It doesn't compile, so far the problem has only cropped up with Mangaged
C++ code and boy are the error message cryptic.  I am not sure if I can
reproduce this problem with actual IL code, but I have made C++ and C#
examples.

> Also, just to help me understand the problem: does this situation where
> we have generate namespace and a class with the same name occur only
> for Mercury code using nested modules?
> 
No it appears with programs where we are trying to use an assembly
written in C#, and then automatically generate a Mercury interface to
this assembly.

I have attached some C# files which mimic the code we currently generate
to to create an interface to Person.cs.

Here is an explaination for the attached C# code.

The C# file person.cs contains a namespace Person and a type Person.

Then we have top.cs which contains the namespace Person_mercury.Person and a
type mercury_code.

Then finally we have the problem file bottom.cs which contains the
namespace Person_mercury.Person__code and the type mercury_code a
function in this type refers to the type Person.Person from Person.cs.
For some reason the C# compiler thinks that we need to look in the
Person_mercury.Person namespace, not the Person namespace!  Aaargh!

There are two ways you can compile this file:
    * rename the Person_mercury namespace to something else
    * don't /r:top.cs when building the file

Pete
-------------- next part --------------
A non-text attachment was scrubbed...
Name: namespace_problem.tgz
Type: application/x-gtar
Size: 687 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20010420/87d8af8e/attachment.gtar>


More information about the reviews mailing list