What about little help with signals and slots checking?

[giesbert]

If I understood correctly, old and new syntax should work, so that would mean, old stuff will go on working, and decoupling also.

[Franzk]

[quote author="Gerolf" date="1308722120"]If I understood correctly, old and new syntax should work, so that would mean, old stuff will go on working, and decoupling also.[/quote]
True that. The encapsulation is achieved by keeping the signals protected, which has to be changed for the new syntax to work. To be honest, that still sounds like a deal-breaker to me.

[jim_kaiser]

I agree with Franzk on the worry about breaking encapsulation (especially the example about having a public aboutToQuit signal which can then called/emitted from another class!). But i'm positive, they will find a solution for that.

[andre]

Encapsulation is already broken with signals and slots. I don't see how making the signals public will break it more than it already is. Even now, you can use this to trigger a signal in another object:

@
QMetaObject::invokeMethod(theOtherObject, "myDangerousSignal", Q_ARG(bool, m_selfDestruct));
@

Making the signal public will make the above a bit easier, but the effect won't be any different:
@
theOtherObject->myDangerousSignal(m_selfDestruct);
@

Same goes for slots, by the way. They are open to the public if a user really wants to, even the ones you declared as private.

Bottom line for me: there needs to be careful consideration if making the signals public is worth the benefit. Making them public may send the wrong message in terms of API design, but the actual protection of the methods does not change. That makes it, in my eyes, not a deal-braker if the benefits are great enough.

[jim_kaiser]

I agree too it's not a deal breaker.. but it is a concern that needs to be addressed. While using the

@ QMetaObject::invokeMethod(myObject, mySignal) @

It is a level of abstraction and it's clear when we want to script the object and make it emit some signal. The normal legal way being the

@ emit mySignal(); @

Which of course cannot be done by classes other than the owner.

But bringing that to the level of a C++ method call is breaking encapsulation.. the goal being to prevent such dangerous access to the class.

[Franzk]

There is a big difference between having to type
@QMetaObject::invokeMethod(theOtherObject, "myDangerousSignal", Q_ARG(bool, m_selfDestruct));@
and just being able to type
@theOtherObject->myDangerousSignal(m_selfDestruct);@
and get away with it because the signal is considered public by the compiler

Edit: Improved sentence.

[dangelog]

I think the thread went a bit off topic when dealing with Qt5 overloads for connect() accepting lambdas, pointer to members etc.

bq. Why MOC cannot do that check?

What you suggest is doable, but moc IMHO is the wrong place to do that. Instead, you should move the logic into the compiler itself, and have it check at compile time (whenever it's possible) that the specified signals and slots in the connect() statement DO exist in the respective classes. For instance, you could write a gcc plugin (in Python) to do exactly that, and emit a warning in case the compiler finds something strange with a connect.

Notice also that any Qt-enabled IDE (YMMV) will help you in writing the right connect statements, and refactoring the relevant code.

bq. Then MOC when meets these extensions – it just performs checking of existence method1 in class1 and it’s definition as signal. Same for slot method2 in class2. Notice that parameters of methods are omited – MOC can take them from declarations of these methods. For example they are both int.

What's exactly the advantage of doing that? And by the way, it's generally wrong. You can have overloads for both signals and slots, therefore more than one match can possibly exist.

[Gourmand]

bq. Instead, you should move the logic into the compiler itself

no, in my idea checking must perform before preprocessing to change additional keywords to fine-tuned SIGNAL and SLOT macros

if only it was built into preprocessor before it's main engine...

bq. You can have overloads for both signals and slots, therefore more than one match can possibly exist.

you just did not read forward, later I told about overloading - if this appears and processor confuses, then it just prints out an error - and extra parameters declaration solves problem

but this all is not interesting for people here, including authors... this could be interesting only for developers who want use old connection style and have check at compile time

bq. Notice also that any Qt-enabled IDE (YMMV) will help you

thanx but I've already got accustomed to QtCreator