Properties macro

[ranfdev]

The implementation is a mess... I will clean it up.

Take a look at the newly added test case to see how it can be used.
I'm interested in comments about the API:

#[derive(Props, Default)]
pub struct Foo {
    #[prop("bar", "bar", "This is a bar", None, glib::ParamFlags::READWRITE)]
    bar: RefCell<String>,
    #[prop("buzz", "buzz", "This is a buzz", 1, 100, 1, glib::ParamFlags::READWRITE)]
    buzz: RefCell<u32>,
}

Currently you can't set more than one flag at a time. Everything else seems to work. Oh, and I need to finish implementing the Parametrize trait for all the type that have a ParamSpec.

Related to #27

[bilelmoussaoui]

Currently you can't set more than one flag at a time

I would not use the flags directly but make them separate attributes like (read/write/notify) and map them internally to the corresponding flag

[ids1024]

Vala supports two types of properties (https://wiki.gnome.org/Projects/Vala/Manual/Classes#Properties):

Properties can either be declared with code that will perform particular actions on get and set, or can simply declare which actions are allowed and allow Vala to implement simple get and set methods. This second pattern (automatic property) will result in fields being added to the class to store values that the property will get and set. If either get or set has custom code, then the other must either be also written in full, or omitted altogether.

So properties can be backed in something like a RefCell with automatic get/set implementations, or manual get/set which may not even have a struct member. I'm honestly not sure what a good Rust API to support both use cases would be, but it seems it should be done in some way.

In addition to properties, GObject has signals, and I think the two should be considered together. (I wrote an idea for signals in #214). Luckily signals are simpler in comparison.

[ranfdev]

The latest API is:

#[derive(Props, Default)]
pub struct Foo {
    #[prop(get, set)]
    bar: Mutex<String>,
    #[prop(get = Self::hello_world)]
    _buzz: RefCell<String>,
    #[prop(get, set = Self::set_fizz, name = "fizz")]
    fizz: RefCell<String>,
}

[jf2048]

Nice to see someone working on this! 😃 It's looking good, I was thinking about this for the last few months and I had a few ideas:

• Should it have flags to auto generate getters and setters? Maybe notify methods and pspec accessors too?

  #[prop(auto_get(pub), auto_set)]
  fizz: RefCell<String>,

  Generates something like:

   impl <Foo as ObjectSubclass>::Type {
       pub fn fizz(&self) -> Ref<String> {
           self.imp().fizz.borrow()
       }
        fn set_fizz(&self, value: String) {
            if self.imp().fizz.borrow() != value {
                self.imp().fizz.replace(value)
                self.fizz_notify();
            }
        }
        fn fizz_notify(&self) {
            self.notify_by_pspec(Self::fizz_pspec());
        }
        fn fizz_pspec() -> &glib::ParamSpec {
            <Self as ObjectSubclass>::properties()[2]
        }
   }

• Or should it generate a "fields" enum to index the properties array, like is common when writing GObjects in C?

  #[derive(Props, Default)]
  #[glib_props(fields)]
  struct Foo {
      // ...
  }

  Generates something like:

  enum FooField {
      Bar = 0,
      Buzz = 1,
      Fizz = 2,
  }
  impl Foo {
      fn pspec(field: FooField) -> &glib::ParamSpec {
          <Self as ObjectSubclass>::properties()[field as usize]
     }
  }

• Should it allow for a custom implementation of ObjectImpl, if someone wants to layer functionality on top of the generated code?

  #[derive(Props, Default)]
  #[glib_props(no_trait)]
  struct Foo { /* ... */ }

  Generates something like:

  impl Foo {
      fn properties() { /* ... */ }
      fn property() { /* ... */ }
      fn set_property() { /* ... */ }
  }

[ranfdev]

auto generate ...

This is already implemented:
#[prop(get)] -> autogenerate
#[prop(get = func)] -> custom
#[prop()] -> not readable

should it generate a "fields" enum

Yes, I could do it, makes sense.

Should it allow for a custom implementation of ObjectImpl, if someone wants to layer functionality on top of the generated code?

The general opinion is "yes". My current idea is to define a trait AutoProps and then call that in ObjectImpl.

[ranfdev]

Should it have flags to auto generate getters and setters?

Sorry @jf2048, I misread. You actually want to generate getters/setters on the wrapper type. I don't know if this is technically possible.
Read the comments above, there's another thread about this in the code comments.

[bilelmoussaoui]

Should it have flags to auto generate getters and setters?

Sorry @jf2048, I misread. You actually want to generate getters/setters on the wrapper type. I don't know if this is technically possible. Read the comments above, there's another thread about this in the code comments.

Well, the code suggested by @jf2048 should actually work just fine because it doesn't impl T but instead it does impl <T as ObjectSubclass>::Type which is the public type :)

[ranfdev]

That syntax is invalid:

impl <#name as ObjectSubclass>::Type {
    fn hi() {}
}

error[E0118]: no nominal type found for inherent implementation
  --> glib-macros/tests/props.rs:20:22
   |
20 |             #[derive(Props, Default)]
   |                      ^^^^^ impl requires a nominal type
   |
   = note: either implement a trait on it or create a newtype to wrap it instead

Explanation: https://stackoverflow.com/questions/49277733/what-is-a-nominal-type-in-the-context-of-an-inherent-implementation

[bilelmoussaoui]

@ranfdev right, but you can generate a trait and implement it for T::Type no?

[jf2048]

you can generate a trait and implement it for T::Type no?

That's what I was getting at, I have been able to do that in some of my experiments. Sorry I should have been clearer, my code above was some really rough pseudocode.

[ranfdev]

but you can generate a trait and implement it for T::Type no?

Yes, I thought about it, but then when you import the type you must import the related trait too, else you don't get access to any method.

It's the best option for now, but it's not perfect

[bilelmoussaoui]

Sorry, reviewing from phone is hard

[melix99]

A feature I see missing is a way to create a property with a WeakRef.

[sdroege]

To move this forward, maybe this PR can be split up a bit? Let's first try to get those paramspec traits merged, for example. That way it can all be reviewed in smaller chunks.

[bilelmoussaoui]

Would you mind rebasing this PR & fixing the test failure?