Re: [Vala] Tryout adding simple support for extension methods to valac

[Philip Van Hoof <philip codeminded be>]

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) {
> }