Re: [Vala] Name Mangling

[pancake <pancake youterm com>]

The same happens when using C keywords like 'asm'. I can't imagine a  
clean solution for this :/

int asm=0;


Sent from my iPod

On Jul 23, 2009, at 1:00 PM, James Cox <jamescox84 googlemail com>  
wrote:

> Hi Everyone,
> Has this been discussed before, or even fixed.  It's to do with the
> way Vala handles the mangling of the names of various symbols, and how
> these rule can create identical names in the C source code.  I propose
> that the Vala compile issues a informative error when such conflicts
> arise.
>
> I've been using Vala for a while now.  I've got to say it's absolutely
> an amazing idea, to use the C+GObject type system as the runtime
> environment for a language is ingenious!  One thing I noticed though
> (I appreciate this would be down to some bad design on the
> programmer's (user'ss) part) is the way Vala mangles the names of
> classes, methods.  It is possible to compile code to the intermediate
> C and then have that code fail when the code is compiled by cc due to
> redefinition of symbols, that had distinct names in the Vala source
> file, but now have the same name in the C source files.  Here are some
> examples:
>
> namespace MyNameSpace
> {
>    class MyClass
>    {
>    }
>
>    // Matches Mangleing of MyNameSpace.MyClass
>    class my_class
>    {
>    }
> }
>
> // Matches Mangleing of MyNameSpace.MyClass
> class MyNameSpaceMyClass
> {
> }
>
> // Redefines the MyNameSpace.MyClass constructor due to matchingh  
> magling.
> public void my_name_space_myclass_new()
> {
> }
>
> I'm not sure of the best way to solve the issues.  Maybe not
> guaranteeing the name of a function that is  declared out side of a
> class/namespace, an error when mangling matches another symbol.  Maybe
> enforce a naming convention for class names, much in the same way as
> Ruby...  Personally I think that keeping the same rules for name
> mangling is best (keeps API looking like a normal GObject API), but
> just make Vala issue a compile time error explaining that a
> redefinition has be made and point the programmer to the two (or more)
> location where it happened.  I'm not sure about where an when these
> problems might arise in normal use, but I think the behavior of the
> language should be specified for when these problems occur.
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list