D8959: Make more signals non-const

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In https://phabricator.kde.org/D8959#171102, @anthonyfieroni wrote:
  
  > Even though, virtual signals ?!
  
  
  Yes, that trick is needed because even in Qt5 no-one has added support to Qt's interfaces logic to allow requiring implementors to provide certain signals (like wanted when interfaces e.g. should provide a property with setter, getter, notifier).
  
  In https://phabricator.kde.org/D8959#171104, @brauch wrote:
  
  > Well conceptually, a signal is only a signature. The const has no meaning conceptually (what would be the difference between a const and a non-const signal). So it makes sense to pick a normalized form -- the non-const one.
  >
  > Practically, the signal gets implemented by the moc and ... does things (call slots), so it's not really a const operation because the slots are also potentially non-const ...
  
  
  Well, one could say the signal method itself does not call those slots. It is rather the one who connects the slots to the signal. Does not completely convince me :)
  
  Another reasoning might be that signals are only needed when a state changes (why else should be a notification done). So the method emitting a signal should be non-const itself, and the signals being non-const enforces that (at least to the point where people are not wildly applying const_cast<>).

REPOSITORY
  R32 KDevelop

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

To: kossebau, #kdevelop, apol, kfunk
Cc: brauch, anthonyfieroni, apol, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171123/773fc1e6/attachment.html>