On Sat, 2005-07-30 at 14:05 +1000, Richard Cole wrote: > So I'm still a bit confused about where the underscores are turned into > dashes. > > property names: (yes) > - registering a property > - getting a property > - setting a property > > signal names: (no?) > - registering a signal > - emitting a signal > - registering a signal callback > > signal details: (no) > - emitting a signal detail > - registering a signal callback > > One doesn't register signal details anywhere does one? > > I recognise that you want to stay backwards compatible, but that you > also want to be as regular as possible. So my argument is for something > regular and expected. > > I would argue that: signal -> no, property -> yes, is simpler than > signal name -> yes, signal detail -> no, property -> yes. Cause it is > more rules and property names sometimes get put into signal details and > so then even this simple statement of the rules is wrong. So I ask, > whose code would break if it was: signal -> yes, property -> yes? By > signal -> yes I mean that both signal names and signal details have > underscores converted to dashes, and by property -> yes I mean that > property names have underscores converted to dashes. > > For someones code to break from signal -> yes, property -> yes, they > would have to have details with both underscores and dashes that needed > to be distinguished. Who would need such a thing? So, you proposal in particular, is that g_signal_emit_by_name() and g_signal_connect() should transform _ to - in details before converting the string detail to a quark? - The fact that details are just arbitrary strings; that they aren't constrained by all the other rules that apply to signal names makes doing that transformation a bit odd. - As you say, it isn't compatible. Compatibility isn't just a "should" it's a must. Can I prove that there are people out there using the detail mechanism for things other than properties? Not off-hand. But we can't just break an API because we don't think anybody is using it. Compatibility trumps consistency every time when it comes to API maintenance. Since there is no legitimate reason (other than the tons of example code that doesn't do it right) to use "_" in signal and property names, I don't think we'd gain a whole lot. Even if compatibility allowed us to change the detail handling at this point. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
