DCOP stuff

[Jarosław Staniek]

Hello everybody,
I put here my discussion on with David Faure on dcopidl and dcopidl2cpp 
features, extensions (and misfeatures?). RFC. Thanks.

== From js at iidea.pl: ===========================

Hi,
Probably it could be erroneous:
generating method that return boolean type (using dcopidl2cpp tool) we 
have code like this (example from generated file 
/koffice/kexi/core/KexiProjectIface_stub.cpp):

------------------------------------------------
bool KexiProjectIface_stub::dbIsAvaible()
{
     bool result; /* shouldn't be initialized to false ?*/
     if ( !dcopClient()  ) {
     setStatus( CallFailed );
     return result;
     }
     QByteArray data, replyData;
     QCString replyType;
     if ( dcopClient()->call( app(), obj(), "dbIsAvaible()", data, 
replyType, replyData ) ) {
     if ( replyType == "bool" ) {
         QDataStream _reply_stream( replyData, IO_ReadOnly );
         _reply_stream >> result;
         setStatus( CallSucceeded );
     } else {
         callFailed();
     }
     } else {
     callFailed();
     }
     return result;
}
------------------------------------------------
Look, 'result' local variable is uninitialised here. I think it should 
be set to false, right? Maybe generated k_dcop method can have 
optionally specified default return value?

However, small patch is in attachment.

--- stubimpl.cpp.orig	Sun Mar 30 19:42:16 2003
+++ stubimpl.cpp	Sun Mar 30 19:45:30 2003
@@ -220,6 +220,8 @@
  			    str << "    " << result << " result";
  			    if (isIntType( result ))
  				str << " = 0";
+			    else if (result == "bool")
+				str << " = false";
  			    str << ";" << endl;
  			}

== From faure at kde.org: ===========================

I think the idea is that you're not supposed to use the return value
if the status is CallFailed...

== From js at iidea.pl: ===========================

I think, returned value should be always deterministic, not random as it
is for booleans. The code for values that self-initializes, like QString
is ok. Also, integer falue _hav_ explicite initialization (example from
koffice/lib/kofficecore/KoDocumentIface_stub.cpp):
--------------------------------------------------------
int KoDocumentIface_stub::viewCount()
{
     int result = 0; /* <<<<<<<<< */
     if ( !dcopClient()  ) {
	setStatus( CallFailed );
	return result;
     }
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
So, I do not know why boolean should be an axception.
Dont we want to deliver consistent, deterministic  behaviour in the
code? User of DCOP services shouldn't use random return vaule.
Additionaly, I see the same applies to double, float and char types and
any variations of signed, and so on.

Most compliers should warn about uninitialized return value such that.
This is another reason to fix it to remove warning.

== From faure at kde.org: ===========================

On Monday 31 March 2003 12:03, Jarosław Staniek wrote:
 > Most compliers should warn about uninitialized return value such that.
 > This is another reason to fix it to remove warning.
Right, I agree with that one.

 > Dont we want to deliver consistent, deterministic  behaviour in the
 > code?
We already do. We always return a status of "CallFailed". That's consistent
and deterministic.

 > User of DCOP services shouldn't use random return vaule.
They shouldn't even use the bool if the call failed.
Think about it - if their bool is like
bEnabled = dcop.callMethod()
then it will be false if the call fails, but if it is
bDisabled = dcop.callMethods(),
it will be false too, so the meaning will be opposite (enabling instead 
of disabling).
Is that consistent? ;)

 > Additionaly, I see the same applies to double, float and char types and
 > any variations of signed, and so on.
Do you have a patch for those?

== From js at iidea.pl: ===========================

David,
In reality it is half-consistent ;^), but better than before, and we
don't have the situation when compiler warns for one type and don't do
it for other type.

 > Do you have a patch for those?

If you want, let me know, and I can prepare the patch that covers all
known (for us) types of uninitialized variables.

Extension: As I wrote before, we can quite easly introduce the default
return value mechanism for dcop methods. Semantically, default value
would be returned if DCOP call failed (maybe it should have name
ON_FAIL(value) or someting). It wouldn't break any current code but
extend it, but maybe requires more discussion on mailing list. I thing
putting more information about given class behaviour into dcop class
interface is valuable. Code that make use of this construction can be
IMO little shorter and clearly. What do you think?

== From faure at kde.org: ===========================

 > If you want, let me know, and I can prepare the patch that covers all
 > known (for us) uninitialized types.
Just for the sake of compiler warnings, yes, I'd like that.

 > Extension: As I wrote before, we can quite easly introduce the default
 > ..

I think the idea is good _if_ the syntax is acceptable. But I'm not sure
what kind of syntax you have in mind...

== From js at iidea.pl: ===========================

Ok, I send it today or tomorrow.

 > I think the idea is good _if_ the syntax is acceptable. But I'm not sure
 > what kind of syntax you have in mind...

I have in mind syntax that do not break the C++ standards, so we can use
  macros as in Q_OBJECT and K_DCOP extensions was introduced and works well:

class MyClass : public DCOPObject
{
   K_DCOP

k_dcop:
	float maximumWeight() DCOP_DEFAULT(100.0);
};

in generated .kidl file:

     <FUNC>
         <TYPE>float</TYPE>
         <NAME>maximumWeight</NAME>
         <RETURN_DEFAULT>100.0</RETURN_DEFAULT>
     </FUNC>

Somewhere in global we would have:
#define DCOP_DEFAULT(arg) /*empty*/

Note that in DCOP_DEFAULT we can even put expressions (or code blocks?),
what can be recognized by dcopidl2cpp and poperly handled in generated code:

	QStringList maximumWeight()
		DCOP_DEFAULT(QStringList() <<"one"<<"two"<<"three");
..it is possible, but for some people little hardcore ;)


Similarly can be added default values for method's arguments.

== From faure at kde.org: ===========================

Looks good to me - but I suggest discussing it on kde-core-devel, 
especially Matthias Ettrich might be interested and have some input.

== end of quotes ==

regards,
Jaroslaw Staniek