doing that as we speak. On Mon, Dec 23, 2019 at 9:52 PM Kevin Ottens <nore...@phabricator.kde.org> wrote:
> ervin added a comment. View Revision <https://phabricator.kde.org/D26127> > > In D26127#582398 <https://phabricator.kde.org/D26127#582398>, @tcanabrava > <https://phabricator.kde.org/p/tcanabrava/> wrote: > > In D26127#582296 <https://phabricator.kde.org/D26127#582296>, @ervin > <https://phabricator.kde.org/p/ervin/> wrote: > > Those data structure look really similar to the ones you introduced in > param() for D26126 <https://phabricator.kde.org/D26126>. It looks like > we'll end up with a Q_GLOBAL_STATIC or such instead of code duplication. > > it's similar but the values are different, the other one is for > parameters, this one for return types, so on the other one we have const > QList<QUrl> & and here is just QList<QUrl>. > I tougth in a way to make them both be the same, but I couldn't find a > way, since some elements will not have the const & in both cases, like > int, uint, double, I prefered to keep the maps separated. > > Well sure, it can't be shared "as is", clearly there's a richer type > missing to tie it all together. This could actually be the start of a > domain model in that application. > > *REPOSITORY* > R237 KConfig > > *REVISION DETAIL* > https://phabricator.kde.org/D26127 > > *To: *tcanabrava, ervin > *Cc: *ervin, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, > bruns >
