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.
regards,
Richard.
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
