On Thu, 2017-10-26 at 10:23 -0500, Federico Mena Quintero wrote:
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.:
Agreed, that's the nicest way for doing this.
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?
I don't know :) I'm fine with not having automatic getters/setters until we figure that one out, or forever even. It's not very painful.
<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>
Separating logic and data seems generally nice, and properties should IMHO just change data trivially (plus taking a mutex, setting a flag that something has changed, etc)... and other code then takes care of applying those changes at a later time (e.g. next time the widget is rendered, next time the GStreamer element processes data, ...). But I guess that's too restrictive, judging from all the code out there that uses properties :) In the end it's a matter of style/taste.
Attachment:
signature.asc
Description: This is a digitally signed message part