Message de Jürgen Schmidt date 2013-01-25 13:55 :
> On 1/25/13 12:44 AM, Andrea Pescetti wrote:
>> Rob Weir wrote:
>>> I also like the idea of marking a function as deprecated, maybe even
>>> supporting the new and old together for a release, to give time for
>>> transition.
>>
>> If at all feasible, I would be for this. Ideally, we should be able to
>> install a legacy extension by: recognizing it's using legacy APIs or
>> conventions; displaying a warning; running it anyway, trying to be as
>> compatible as possible.
>
> this would be indeed nice and if easy possible we would probably do
> that. But the reality is that we don't have the resources to spent
> enough time on this.
OK, we don't have enough resources, but then why spend scarce resources on
secondary aspects of the API ? Even if it is simple to do, it's not a sufficient
reason. Better develop or correct something that was requested by bug reports
and that appears within available resources.
I am not against incompatible changes, if it is inevitable in order to provide a
new feature very valuable for the API users. But the changes proposed by Ariel,
as far as they are described, do not add anything useful for the API user.
> We have as deprecated marked API's and I am sure that people will still
> use it. These API's are probably deprecated since > 3-4 versions and we
> should be save to remove them. But I am sure people would complain about
> it if there macro, solution won't run anymore.
That's why I would prefer adding new services/interfaces, and keep the old ones
with a mention : DEPRECATED, see so-and-so. A perfect example is service
com.sun.star.document.DocumentInfo. You can be sure that there are still many
users of this now obsolete service. They are not aware of the new service, and
don't care.
But you can also find many IDL pages flagged DEPRECATED without indication of an
alternative, nor simply saying that the feature is killed. This is not helpful
for the poor API user.
Bernard
|