public G add<G> (G a, G b) {}
and check the type of your numbers inside the function ? :)
2014-05-15 19:48 GMT+02:00 geovanisouz...@gmail.com <
geovanisouz...@gmail.com>:
> 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:
>
> 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?
>
> 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.
>
> Thank you.
>
> --
> @geovanisouza92 - Geovani de Souza
> _______________________________________________
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
