GNOME.org
 

Re: [Vala] About method overloading, constructor overloading and extension methods

Also method overloading is the worst mistake a language could do. It's
tricky, it does not always work as the user expects, it has weird
semantics. Even if we didn't care about C naming, I would never implement
method overloading in a sane language.


On Thu, May 15, 2014 at 8:22 PM, Evan Nemerson <evan coeus-group com> wrote:


On Thu, 2014-05-15 at 14:48 -0300, geovanisouza92 gmail com wrote:

Hello guys,

I'm thinking about the reasons behind the pseudo constructor overload,
method naming convensions and C# entension methods.

I don't look deep in Vala compiler implementation, but can suggested
something to resolve this issue, based in what I see in generated C

code: a

"name binder".

Some kind of naming engine to rule 'em all, where the compiler can

register

all found method names (with types, the complete signature), and from the
code writer can peek the C method names. For example, in the code:

int add(int a, int b)
{
    return a + b;
}

int main(string[] args)
{
    var result = add(2, 3);
    print("Result: %d\n".printf(result));
    return 0;
}


All works fine, and the resulting C code:

gint add (gint a, gint b) {
 gint result = 0;
gint _tmp0_ = 0;
 gint _tmp1_ = 0;
_tmp0_ = a;
 _tmp1_ = b;
result = _tmp0_ + _tmp1_;
 return result;
}


gint _vala_main (gchar** args, int args_length1) {
gint result = 0;
 gint _result_ = 0;
gint _tmp0_ = 0;
 gchar* _tmp1_ = NULL;
gchar* _tmp2_ = NULL;
 _tmp0_ = add (2, 3);
_result_ = _tmp0_;
 _tmp1_ = g_strdup_printf ("Result: %d\n", _result_);
_tmp2_ = _tmp1_;
 g_print ("%s", _tmp2_);
_g_free0 (_tmp2_);
 result = 0;
return result;
}


int main (int argc, char ** argv) {
#if !GLIB_CHECK_VERSION (2,35,0)
g_type_init ();
#endif
return _vala_main (argv, argc);
}


Well, fine. But if I declare another method, like:

float add(float a, float b)
{
    return a + b;
}


The compiler forbid me.

I know that the recomended way to solve this is use diferent names for
methods:

float add_float(float a, float b)
{
    return a + b;
}

int add_int(int a, int b)
{
    return a + b;
}


And again, all works.

But, if this is the recommended way to make it work, why the compiler
itself doesn't do this for me? I would that this "naming binder" can

expand:

It is called mangling.  See https://en.wikipedia.org/wiki/Name_mangling

We don't do it because we care about the C API—libraries written in Vala
are meant to be usable from other languages, which means providing a
*good* C API.  This simply can't be done automatically—the only way
would be to force the user to choose the mangled names themselves, so
you would end up with something like

        [CCode (cname = "add_float")]
        public float add (float a, float b);
        [CCode (cname = "add_int")]
        public int add (int a, int b);

If you still have to provide the names yourself, the only "benefit" is
that in Vala you can just use add (instead of add_float and add_int).
The drawbacks include the Vala API being different from other languages
and the code being more difficult to read and reason about.



float add(float a, float b)
int add(int a, int b)


To something like this:

gint add__int__int (gint a, gint b)
gfloat add__float__float (gfloat a, gfloat b)


Anyway, if the C compiler support overloading, why Vala does not?


It doesn't.  Vala targets C89, and C doesn't support overloading (well,
generic selection) until C11.  MSVC still doesn't support C99, let alone
C11, and GCC doesn't support _Generic until 4.9 (which was just released
about 3 weeks ago).


In case of extension methods, it can be expanded too, and only gain

context

when included and used in source files. In C the
pseudo-object-oriented-programming is made passing the "this" (or in Vala
"self") variable to each function, thing made transparently by
compilers/runtimes of other languages.

Extension methods is basically like C functions (receiving a "self"
reference) and mapped/validated by compiler when
"object.extension_method()" is used.

So, which effort is necessary to make Vala compiler accept this feature?

I

think that a centralized naming logic can help in these cases.


Extension methods are tricky, but we could conceivably support them (see
<https://bugzilla.gnome.org/show_bug.cgi?id=681097>).  That said, there
isn't any need for additional name mangling logic.  The name can (and
should) be generated based on the location of the extension method, not
the object being extended.


-Evan

_______________________________________________
vala-list mailing list
vala-list gnome org
https://mail.gnome.org/mailman/listinfo/vala-list





-- 
www.debian.org - The Universal Operating System
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]