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 <[email protected]> wrote: > On Thu, 2014-05-15 at 14:48 -0300, [email protected] 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/vala-list > > -- www.debian.org - The Universal Operating System _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
