Re: Bikeshedding the gnome-class mini-language

["Zeeshan Ali (Khattak)" <zeeshanak gnome org>]

Hi,

Jumping in the middle of a conversation here, apologies. :)

On 26 October 2017 at 17:23, Federico Mena Quintero <federico gnome org> wrote:
> [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...

With struct (or in Vala's case: Object) fields, you don't get the
advantages of properties:

* Notification signals on changes.
* mark them virtual so that subclass can implement them differently.
e.g the baseclass can choose to just go with the default setter/getter
but subclass might want to do something special on/before/after
setting/getting the property.

-- 
Regards,

Zeeshan Ali