> On July 5, 2014, 9:33 a.m., David Faure wrote: > > src/lib/plugin/kpluginmetadata.h, lines 204-205 > > <https://git.reviewboard.kde.org/r/119079/diff/3/?file=286685#file286685line204> > > > > Make member vars private. > > > > It's not like deriving from a value class makes any sense anyway, and > > this makes future changes possible (as long as the object size doesn't > > change). > > Alexander Richardson wrote: > I thought applications that have extra metadata keys could just extend > this class to provide a getter for that. > > class FooPluginMetaData : public KPluginMetaData { > public: > using KPluginMetaData::KPluginMetaData; > QString fooBar() { > return m_metadata["X-Foo-BarInfo"]; > } > } > > But I can make them private anyway if you think this is not a valid > use-case > > Alex Merry wrote: > Well, you can have a public or protected method instead, like > QString value(const QString &value) { return m_metadata.value(value); }
Deriving from KPluginMetaData just doesn't make sense. How would apps do that, when the API from KPluginLoader returns them a QVector<KPluginMetaData> in the first place? They could copy each item into something else, but then better use composition than inheritance for that "something else", to avoid any risk of slicing (= copying from derived to base and losing the derived stuff). This is the same reason why inheriting from QString or any other value class is a very bad idea (TM). Alex's suggestion sounds good, in any case (with a "const" before the '{') -- as long as the docu doesn't mention inheriting from KPluginMetaData, of course :) > On July 5, 2014, 9:33 a.m., David Faure wrote: > > src/lib/plugin/kpluginmetadata.cpp, line 30 > > <https://git.reviewboard.kde.org/r/119079/diff/3/?file=286686#file286686line30> > > > > Not static global objects in libraries, they slow down application > > startup and can lead to issues due to the undefined order of > > creation/destruction. > > > > Use static const char[] here, and convert to QString at usage time. > > > > I guess 16-bit readonly data would be better, but I'm not confident > > about how to write that portably. > > Alexander Richardson wrote: > Yeah thats right, I though QStringLiteral didn't cause a global > constructor call, but clang -Wglobal-constructors proved me wrong. > > Since these keys are used only once (except for MetaData), I guess I > could just get rid of those global statics and insert a QStringLiteral in the > function that needs the string Right. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119079/#review61635 ----------------------------------------------------------- On July 5, 2014, 3:20 p.m., Alexander Richardson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119079/ > ----------------------------------------------------------- > > (Updated July 5, 2014, 3:20 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kcoreaddons > > > Description > ------- > > This class simplifies reading the metadata from a qt plugin by providing > type safe accessor functions for the standard plugininfo keys that are > also used by the .desktop file based KPluginInfo > > KPluginMetaData: Read the translated value for name and description > > The "Name" and "Comment" fields of the metadata should be translated > since they will be shown to the user (e.g. in the plugin selection > dialog) > > Add a unit test for KPluginMetaData > > > Add KPluginMetaData::findPlugins() > > > Add a unit test for KPluginMetaData::findPlugins() > > > Introduce KPluginLoader::instantiatePlugins() and add a unit test > > This method allows easily instantiating all plugins in a given directory > > KPluginMetaData::pluginName() was changed to return the base name of the > plugin file if no plugin name was set in the JSON metadata > > > Diffs > ----- > > autotests/CMakeLists.txt 75d12932b36fcfe4ae1d538176ef9f85f60f15dd > autotests/kpluginloadertest.cpp c8225c02de3a64cae29d88954700dbc6f03ff1b0 > autotests/kpluginmetadatatest.cpp PRE-CREATION > src/lib/CMakeLists.txt 26eb5a1d4d56742a3395ba2645290bea15aee181 > src/lib/plugin/kpluginloader.h 0b7a53d3b879cec1d755b849d9d8c640d251a379 > src/lib/plugin/kpluginloader.cpp 9b3c5b6aec537b03b0d8341b33f6f4d7a76c8344 > src/lib/plugin/kpluginmetadata.h PRE-CREATION > src/lib/plugin/kpluginmetadata.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/119079/diff/ > > > Testing > ------- > > Added a unit test > > Should easily allow loading all plugins from a given directory without > needing kbuildsycoca > > > Thanks, > > Alexander Richardson > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel