Re: Incorrect definition of property in ATK

["Padraig O'Briain" <Padraig Obriain Sun COM>]

> To: "Padraig O'Briain" <Padraig Obriain Sun COM>
> Cc: gtk-devel-list gnome org, desktop-devel-list gnome org
> Subject: Re: Incorrect definition of property in ATK
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/21.1
> MIME-Version: 1.0
> 
> 
> "Padraig O'Briain" <Padraig Obriain Sun COM> writes:
> 
> > The property accessible-caption of AtkObject is defined as a string but 
should 
> > be defined as an AtkObject.
> > 
> > Is correcting this permitted or is it prevented by the API freeze?
> 
> (I'm not sure I would call it an API "freeze" at this point, since
> we've already released; it's just the requirements of API compatibility within
> a stable release)
> 
> I don't see an accessible-caption property. Do you mean:
> 
>   g_object_class_install_property (gobject_class,
>                                    PROP_TABLE_CAPTION,
>                                    g_param_spec_string 
(atk_object_name_property_table_caption,
>                                                         "Accessible Table 
Caption",
>                                                         "Is used to notify 
that the table caption has changed ",
>                                                         NULL,
>                                                         G_PARAM_READWRITE));
> 
> There is a class of API changes that it makes sense to allow, because
> the API mistake that is being fixed is so blatant that nobody could
> have possibly used them in the broken state. For instance, if you had
> defined the property to be a double, it's very unlikely anyone would
> have written code that depended on that.
> 
> This doesn't really seem to fall into that category; for
> "accessible-table-caption" to be a string makes some sense, even if it
> wasn't what you had planned.

This is doubtful as the caption in the AtkTable interface is an AtkObject.
I do not think that anybody can use "accessible-table-caption" as currently 
defined.

> 
> I don't think that nobody we can find is depending on a particular API
> is sufficient grounds to make an incompatible API change; I think, as
> a general principle, we need to have some confidence that nobody
> _could have_ depended on the API. 
> 
> We are clearly going to have some problems where we made API screwups
> that aren't fixable, and will have to work around them in the future
> by adding alternate API; say here, an "accessible-caption-object"
> property. 
> 

What timescale do you have in mind for allowing adding of alternate API?

Padraig

> The alternative to adding some ugly workarounds is to have people losing
> faith in our compatibility guarantees, and that's just not acceptable.
> 
> Regards,
>                                         Owen
> 
> Notes:
> 
>  * I don't really understand the function of this API in detail, so I'm 
>    really talking here in general terms. 
> 
>  * The other alternative would be to declare ATK an unsupported use-at-your-
>    own-risk API. If we were going to do that, we really should have done
>    that with the 2.0.0 release, but we still could conceivably do that now.
>    But it would clearly conflict with promoting ATK to application 
>    and 3rd-party-widget authors.