[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