Luca Bruno schreef op 14/10/2013 18:17:
Thanks for your contribution :-)
np. Right now it's just an experiment of course. My yearly "trying to
understand vala's code" project ;)
A couple of points:
1) Patches/feature requests go to bugzilla, unless you want them to be
forgotten and eaten by the darkness :) IIRC there's already a bug
about that.
I agree. The patch is so unfinished, however, that I don't think it's
ready for official proposal yet.
2) Instead of defining methods without a class scope and
special-casing/altering the syntax of parameters, I'd suggest either:
extend class Test {
public void method () { }
}
Makes sense.
which adds a namespacing and makes the method look like more an
instance method in its usage and definition.
About namespacing I guess the idea would be to let the code writer add
the namespace to the API, and generate C code that way?
ie.
namespace Test {
extend Class Object {
public void method() {
}
}
}
Would result in a C API like:
void test_object_method ();
Instead of
void object_method(); which could more easily name-clash.
I wonder if the namespace of Object should be added?
ie. void test_g_object_method(); instead of test_object_method() ?
For that I guess I should create a 'Object' Vala.Class in the (new)
namespace 'Test' instead of finding GLib.Object in context.root?
For finding what to generate during code writing, I'm guessing something
similar to how subclassing works needs to be added for extended classes
... (instead of just cl.add_method and let crazy magic do its work,
which is what I did now and which of course doesn't work for classes
that aren't in the same .vala file).
or:
[Extend]
public void method (Test this) {
}
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
