GNOME Bugzilla – Bug 620177
Property notification is broken for some names.
Last modified: 2010-08-20 15:29:54 UTC
Some propertie names get changed when CCode is generated, therefor some signal notificatiosn do not work. Example: {{{ class Foo : Object { public int val { get; set; } public int bogus_val { get; set; } public Foo() { this.notify["val"].connect( () => { debug("Val has been changed."); }); this.notify["bogus_val"].connect( () => { debug("bogus_val has been changed."); }); this.notify["bogus-val"].connect( () => { debug("bogus_val has been changed, but as bogus-val."); }); } } void main() { Foo f = new Foo(); f.val = 42; f.bogus_val = 42; } }}}
So we would expect prop_name to work over prop-name? That probably makes sense in Vala world.
Then the problem is that Vala creates prop_name signal rather than prop-name. I really vote for prop-name.
Created attachment 162521 [details] [review] connect Object.notify with property canonical name This patch has to be applied after attachment 159853 [details] [review]
Well, you should be able to use the same name as the signal has in the vala code. as not every user does know how those names get mangled ...
IMO, the most logical thing (from the Vala point of view) would be to allow using the property itself instead of a string. Such as this: this.notify[bogus_val].connect
Closing as INVALID as per comment in bug 615262. As long as we use strings here, I don't think we should try to be clever here. (In reply to comment #5) > IMO, the most logical thing (from the Vala point of view) would be to allow > using the property itself instead of a string. Such as this: > > this.notify[bogus_val].connect This would be ambiguous in case of a string property (do you want to use the string returned by the property or rather the stringified version of the property itself) and strange in other cases.