[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Binary compatibility summary 4.5.1->4.5.2
From:       Parker Coates <parker.coates () kdemail ! net>
Date:       2010-10-05 20:27:46
Message-ID: AANLkTinZmVBXPvd0LRRqCGaycrYqRs4_FJ8Ob-4vfq1h () mail ! gmail ! com
[Download RAW message or body]

On Tue, Oct 5, 2010 at 16:09, Modestas Vainius wrote:
> On antradienis 05 Spalis 2010 15:06:41 Lubos Lunak wrote:
>>  The complete check is at http://ktown.kde.org/~seli/abi/ . If there are
>> any public libraries not included, please say so. Also note that in this
>> case there are few harmless false positives caused by transitioning to
>> Qt4.7 at the same time.
>>
>>  There is one BIC problem, in kdebase/workspace:
>> libweather_ion removes
>> IonInterface::resetCompleted ( IonInterface::IonInterface* p1, bool p2 )
>
> Is removal of signals BIC? If I understand correctly, code using that signal
> may lose some functionality but it won't crash (nor rebuild of the code would
> change anything) because connection to signals happens entirely at run time. I
> have also seen signal removals in kdelibs and nobody complained then.

Signals are just private methods with fancy wrapping. So I'm pretty
sure removing them is a BIC.

For example if class B is a friend of class A, then B can emit A's
signals. In the very unlikely case that A removed a signal, but B was
not updated, B trying to emit the signal would obviously cause major
issues.

Of course in reality, I'm not sure if this is actually an issue or not.

Parker

[prev in list] [next in list] [prev in thread] [next in thread]