Re: Problems with Properties and Notify Signal Parts

[Richard Cole <rcole itee uq edu au>]

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.