Re: Incorrect definition of property in ATK

[Owen Taylor <otaylor redhat com>]

"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.

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. 

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.