D17078: Make it possible to use KAboutData/License/Person from QML

[Michael Pyne]

mpyne added a comment.


  In D17078#363886 <https://phabricator.kde.org/D17078#363886>, @apol wrote:
  
  > In D17078#363772 <https://phabricator.kde.org/D17078#363772>, @anthonyfieroni wrote:
  >
  > > You can't change parameters in methods or constructors, it's a BIC.
  >
  >
  > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
  
  
  To be clear, it is possible to have a change in default values be BIC (as the page describes). The updated code has to still work in compatible fashion if called with old default values (if any), since that is what existing application binaries would have used.
  
  There weren't default values before and even if there were, there's no change in behavior in the methods, so this change would be BC. From a source compat perspective, the changes made here do result in `KAboutData` becoming implicitly constructible when it wasn't before, which we may not want. Then again, maybe we do?

INLINE COMMENTS

> kaboutdata.h:551
>       */
> -    KAboutData(const QString &componentName,
> -               const QString &displayName,
> -               const QString &version
> +    KAboutData(const QString &componentName = {},
> +               const QString &displayName = {},

Do we want to make this constructor `explicit` since the new default values now make it possible to construct a `KAboutData` with no parameters at all?

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D17078

To: apol, #frameworks, dfaure
Cc: mpyne, broulik, anthonyfieroni, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181122/20988ef9/attachment.html>