> On March 11, 2014, 11:17 p.m., Aleix Pol Gonzalez wrote: > > src/kcompletionbox.h, line 228 > > <https://git.reviewboard.kde.org/r/116747/diff/1/?file=253404#file253404line228> > > > > I wouldn't leave the implementation here. Move it to the .cpp file, > > this way it can be changed in the future, if it's required for some reason. > > > > Also there's a typo in the method name. > > David Gil Oliva wrote: > Alex Merry inlined deprecated methods in > https://git.reviewboard.kde.org/r/116012 , so I thought that it was the way > to go... > > Alex Merry wrote: > Well, there's a balance to be struck: putting them in the header ensures > there is no runtime cost to programs that don't use the deprecated methods, > as the code should be optimised away, that the library is always > binary-compatible even if you compile it with deprecated code disabled > (*_NO_DEPRECATED) and makes the header code document how to replace existing > calls. The downsides are an inability to fix the code later and an inability > to access members of a private d-pointer class. Neither of those are an > issue here, as we're just renaming the method. > > tl;dr: I disagree with Aleix, and think it should stay in the header. > > Oh, and Aleix: could you please select the whole method when you're doing > a comment like this, rather than just the first line? Otherwise it's a pain > to see what you're referring to. Thanks :-)
Well, I wouldn't bother about runtime penalty given that it's deprecated and we shouldn't be using it anyway. Also we can't make assumptions on how things are going to be optimized. But it's ok, I don't think it's worth discussing further, I doubt this is going to be a problem in the future. On March 11, 2014, 11:17 p.m., David Gil Oliva wrote: > > Have you looked through the uses of the "un-slotted" methods? > > (lxr.kde.org). Maybe there's a reason for that... :/ > > David Gil Oliva wrote: > Maybe I'm totally wrong, but I can't imagine any way that a getter can be > useful as a slot. > > connect (widget, SLOT(valueChanged(), completionBox, > SIGNAL(isTabHandling()); > > Does it make sense? ¿?:-/ > > Alex Merry wrote: > Non-void slots are only useful if they work as a slot (ie: have some sort > of side-effect) and might be called directly or with > QMetaObject::invokeMethod(). If the method is const (like a getter), there's > no point having it a slot at all; if you want to be able to use it with > invokeMethod, you can just make it Q_INVOKABLE. Well, having const methods as slots doesn't make sense indeed, if it's not for exposing on the meta object system, that's why I said you could do a fast lxr. I just did, didn't find anything relevant. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/#review52703 ----------------------------------------------------------- On March 11, 2014, 10:32 p.m., David Gil Oliva wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116747/ > ----------------------------------------------------------- > > (Updated March 11, 2014, 10:32 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kcompletion > > > Description > ------- > > Clean up KCompletionBox > > -canceled() -> cancelled (private method) > -Deprecate sizeAndPosition() --> resizeAndReposition() > -Remove old comments and commented-out code > -Move some slots to be normal methods, since they don't seem to be able to > work as slots. > > > Diffs > ----- > > src/kcompletionbox.h 09b7527 > src/kcompletionbox.cpp 92e87b3 > > Diff: https://git.reviewboard.kde.org/r/116747/diff/ > > > Testing > ------- > > It builds and tests pass. > > > Thanks, > > David Gil Oliva > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
