Re: Bikeshedding the gnome-class mini-language

[Federico Mena Quintero <federico gnome org>]

[replying to Adrián and Sebastian together, about default
setters/getters]

On Thu, 2017-10-26 at 10:53 +0200, Sebastian Dröge wrote:
> Same opinion here as Adrian, I don't like it :) A where clause seems
> nicer.
>
> Also I like his other suggestion to auto-derive the setter/getter for
> the trivial cases (but that needs some thought for thread-safe
> GObjects then, as for those you'd like to take a mutex somewhere when
> accessing the values)

I do like Adrián's suggestion about "where"; I'm putting it in the
notes doc.

Also, thanks for reminding me about mutexes and such.  In the code
generator as it is right now, we create a function

  fn get_priv(&self) -> &FooPrivate;

The user's method implementations use self.get_priv() to get the
private structure.

This is a &FooPrivate, not &mut FooPrivate.  In the tests/examples we
have right now, the assumption is that the user will implement interior
mutability as they see fit, e.g.:

  struct FooPrivate {
      x: Cell<i32>,
      y: RefCell<String>,
  }

It would be easy to change the code generator to make get_priv() return
a &mut FooPrivate, but I'm not sure if this is the most Rusty thing.

I don't know how we could have automatic getters/setters if the user is
forced to do interior mutability in this arbitrary way - how would the
getter/setter know how your field is wrapped?

<rant>
Personally I don't like automatic setters/getters very much.  My
reasoning is that if you are changing an object's property you really
want something else to happen (e.g. make a widget redraw itself).  If
your object is just a bag of state with no side effects, you may as
well use a struct...

(Conversely, properties with side effects scare me in C#, because they
don't look like function calls.  Maybe they don't bother me as much in
GTK+ since your code actually looks like it's calling a function when
it sets a property.)
</rant>

  Federico