On Sun, 2005-07-31 at 12:38 +1000, Richard Cole wrote: > Owen Taylor wrote: > > >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. > > > > > Ok. > > So am I right to believe the situation is: property names -> yes, > signals -> no. There are constraints on signal names, (you get warnings > if you violate them), but there's no underscore translation? I'm not > arguing for anything now, just asking to see if I have it straight. Signal names are treated more or less the same as property names - there might be some differences in how things like mixed - and _ work, but the basics are the same ... you can use either - or _. The difference is in detail strings - the thing after the :: in notify::foo-bar There is no magic in detail names, so if a detail name is a property name (like for the notify signal) it much match the *real* canonical property name, which has -, not _. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part