D18420: Use enum to identify AbstractAspect

Alexander Semke noreply at phabricator.kde.org
Sun Jan 27 10:10:01 GMT 2019

asemke added a comment.

  In D18420#400631 <https://phabricator.kde.org/D18420#400631>, @croick wrote:
  > If I had known in advance...
  > I applied the `type()` identifier where I thought it reasonable.
  >  The naming is still a little unfortunate, but I cannot name the enum elements as their corresponding classes, because then the compiler doesn't know whether the enum type is meant or the class. Do you have a better idea than a "Type" suffix?
  Yes, the naming is sub-optimal somehow... I think what we're trying to achieve here is kind of compile time reflection capabilities where c++ is lacking a lot  of support for. And we're trying to add new stuff on top of Qt's meta-object system <http://doc.qt.io/qt-5/metaobjects.html> which already tries to overcome some of the limitations of the c++ language.
  Should we try to utilize QMetaClassInfo <http://doc.qt.io/qt-5/qmetaclassinfo.html> and simply set a new property "classtype" to the corresponding value of the new enum you introduced? With this we'd only need to add a Q_CLASSINFO line in every header and don't need to touch the constructors and the cpp files. At run-time, we read this value out of QMetaClassInfo, cast it to the enum and use it in the switch-case block.
  > In some place there are checks for a non-existant "FileDataSource". I deleted those for now, since I don't know what they are referring to. Is that called "LiveDataSource" now?
  Yes, FileDataSource was renamed to LiveDataSource later. Thanks for cleaning up here.

  R262 LabPlot


To: croick, #labplot
Cc: asemke, kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20190127/f1c6d9d9/attachment-0001.html>

More information about the kde-edu mailing list