On 2020-02-21 13:00, Ville Voutilainen wrote:
On Fri, 21 Feb 2020 at 14:58, Sérgio Martins <sergio.mart...@kdab.com>
wrote:
> Why do I need to know that it's a signal being emitted? How is that
> "vital information"? I could just as well
> invoke any other callback, but I find myself not exactly yearning for
> being able to write
> callback somethingHappened();
Signals have different semantics than regular functions.
In what way?
If I'm reading the body of makePlane() I can ignore the signal
emissions, as they aren't important for how a plane is made, they just
inform whoever is listening.
That doesn't seem to be correct in general. Some signals absolutely
must be emitted
for clients to work correctly.
Signals in the public interface of a self-contained class are not
important to understand the implementation of said class.
Example:
https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qabstractslider.cpp.html#_ZN15QAbstractSlider17setSliderPositionEi
When reading what QAbstractSlider::setSliderPosition() does, I won't
check which slots "emit sliderMoved" triggers, but I will
step into triggerAction(SliderMove);
I'm sure you can find counter-examples where the triggered slot does
something very important for the class that's emitting, I wouldn't call
it self-contained though.
Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
