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
Attachment:
signature.asc
Description: This is a digitally signed message part