Re: Bikeshedding the gnome-class mini-language

On Tue, 2017-10-24 at 13:58 -0500, Federico Mena Quintero wrote:
Hey, all!

I'm making very good progress with the rewrite of gnome-class.  I've
figured out how to port it gradually from lalrpop and the old proc-
macro scheme of things, to proc-macro2 and syn/quote.

Good work :)

See below for my opinion on the colour of the bikeshed, feel free to
ignore everything ;)

By default, the answer to many things here is "what does Vala do?"
This is probably often the right thing syntax-wise.  We can make it
more Rust-like as needed.

Sounds like a good guideline, and C# as a fall-back.

"struct CounterPrivate" is your private struct.  Each class must have
one and only one such structures.

Do you plan to also add support for public fields in the instance

private_init() is a mandatory function that gets called during
initialization; you return an initialized private struct, and *that*
becomes the initial value of what gets put in the
g_type_class_add_private() chunk.

This should probably take the instance as parameter, or a different
function for hooking into instance_init would be useful. To set-up any
things that might be necessary for the base-class to properly
initialize everything.

As an alternative, I want to make it possible to specify
#[derive(Default)] for your private struct, and thus not having to
specify a private_init():

Then it should also be possible to impl derive for the struct manually,
the default derived impl is not always possible/correct :)


Vala supports a construct{} block, which gets called after all
properties have been set.  It uses GObjectClass::constructor.  I
haven't decided

Could also use a construct {} block for that, it seems like a
reasonable choice. Similarly for class and base construct blocks.

on this yet, nor on how the following from Vala would work:

    public MyConstructor (int a, int b, int c) {
        Object (some_construct_only_prop: a, some_other_prop: b); //
construct superclass
        this.my_own_prop = c;

I assume this would only take CONSTRUCT properties, and not all of
them, and there can only ever be a single constructor like this?

Problem: how would the code generator know which superclass struct
has the .foo field in order to override it?  Should we specify this
overriden method like

  override fn SuperClassName::foo(&self, ...);


Seems ok to me, it would also be a solution for an interface and base-
class having the same method name.

Visibility: the code generator assumes that all the "fn" that you put
inside a class are public.  Should we instead allow "fn" and "pub


Should virtual methods be declared as "virtual pub fn"

virtual implies public IMHO

Third alternative, also Rust-like, with "impl" items outside the

gnome_class! {
    class Foo: Superclass, Iface1, Iface2 {
        // ...

    impl Iface1 for Foo {
        fn method_1(&self, ...) {
            // code

    impl Iface2 for Foo {
        fn method_2(&self, ...) {
            // code

I prefer this, but you don't even have to specify the interfaces on the
class line then. It's redundant there.

Creating new interfaces

I haven't decided this yet.  Maybe something like

gnome_class! {
    interface Foo {
        virtual fn blah(&self, x: i32) -> bool;
      virtual fn bleh(&self, y: *const c_char);

I.e. make it similar to "trait", except that the "virtual" keywords
are there to remind you that you are not in Rust land?

I like that


All looking good to me

I haven't though of how to specify signal accumulators, or if we even
need them.  Is there a non-obscure case that needs them?

We use them quite often in GStreamer. You basically need them whenever
you have a non-trivial return value, or you want to use your return
value to decide if further signal handlers have to be called.
I can give examples if needed.

You could provide them by name in the signal attribute.

What about the class/default handler, how would you handle that?


I took some notes about this, but they are far from final.  Vala has
good examples on what the syntax may look like; it borrows from C#,
which is nice.

The C#/Vala way seems good to me.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]