Re: Problems with Properties and Notify Signal Parts

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

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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]