SIC in KIO master

[Harald Sitter]

On Fri, Aug 29, 2014 at 8:26 PM, David Faure <faure at kde.org> wrote:
> On Tuesday 26 August 2014 16:29:23 Harald Sitter wrote:
>> alohas,
>>
>> it would appear to me that a recent change in kio [1] was rather,
>> very, entirely source incompatible (one could argue binary but let's
>> not go there).
>>
>> Say I had the following in my application using kio 5.0/1:
>>
>> connect(copyjob, &CopyJob::aboutToCreate, this, &MyThing::onABoutToCreate);
>>
>> my application would no longer compile with 5.2 :'(
>
> Yes. But I wager that there is no such application, because CopyInfo is not
> documented in the api docs, so the only way to read what's in there is to open
> copyjob.h, and there it was marked as @internal
> and with
> /// FIXME: If this is internal, why is being used in a public signal below?

I think most IDE's will care very little about fixme comments or
doxygen coverage when offering autocomplete options.

>> Can we please revert and deprecate instead?
>
> That wouldn't allow to fix that FIXME, i.e. to make CopyInfo internal for
> real.
>
> This signal was added for kde3's kdesktop, and has been useless ever since.
> Its documentation shows why it's mostly useless - the urls in there aren't
> even final, in case the user chooses "rename" in a conflict dialog.
>
> From a pragmatic point of view, I can't see what this could possibly break,
> other than language bindings, which is how you found this, I assume?

I found it by actually doing ABI checks. And I really think there is
nothing pragmatic about breaking ABI when the library is supposed to
be ABI stable.

For example imagine someone using copyjob and being overly eager and
simply connecting all signals to dummy slots, you know, in case they
might need them in the future (like people subclass QObject without
changes in case they might need to expand their own object derivates)
. It most definitely would not be the weirdest thing I have seen
library users do.

That being said, IMHO it would be perfectly reasonable to deprecate
the signal and *perhaps* even make it non fuctional (as in: it's never
emitted). At the very least this would prevent SC/BC issues.

HS