On Wednesday 26 January 2011 10:46:56 paul [dot] chavent [..] ... wrote:
> Hi RTT-devs.
>
> I'am trying to make a patch for the bug '802 : Test if a peer has an
> operation/property'.

To first set a misunderstanding straight, If you want to check for a peer's
property/operations etc, you need to call:

peer->provides()->hasProperty("foo")
peer->provides()->hasOperation("bar")

provides() returns the Service Object you want to query. Since a component can
have multiple services, a global 'TaskContext::hasProperty' function is not
meaningful, since it would only be able to query the 'top level'/'this'
service of the component, and not any subservice. While with provides, you
would write:

peer->provides("scripting")->hasOperation("runScript")

So I'm not eager to add these functions to TaskContext.hpp.

>
> I submit you a first attempt. For ports, attributes and properties, it
> should be ok. But for operations it's not definitive.
>
> I need your help because i don't understand the Service + Operation
> philosophy.
>
> I add an hasOperation method to the TaskContext class. But i can't
> implement it with (Service::getOperation != 0) because the behavior should
> be different (mustn't display the message). Moreover i can't implement a
> Service::hasOperation because it already exists.
>
> The problem is that the Service seems to have two kind of operations. The
> Service's methods hasOperation and getOperationNames for example work on
> its simpleoperation member, and, getOperation for example work on its
> OperationInterface base class.

Correct. We keep track of both C++ operations and of 'remote' operations with
the same object (Service). When a local C++ operation is added, it appears in
both lists, if a remote operation is added (or a script function for example)
it only apears in the 'remote' list.

>
> In hasOperation and getOperationNames, the calls to OperationInterface
> (hasMembers and getNames) are commented out. So i would like to have a bit
> of history on what happened here : - should the getOperation method take
> care of simpleoperation ?
> - should the hasOperation method take care of OperationInterface ?
> - isn't it possible to have only one type of operation ?
> I found the current implementation very complicated.

It's because you're touching the first layers of the 'middleware' aspect in
RTT. At some point, we distinguish between local operations and remote ones.
hasOperation() only returns true if the operation is local in this component
or in this process. Meaning if you call it on a peer component, it might
return false always (because the peer is in another process for example).
hasMember() checks for the operation across processes.

Now I think myself this makes no sense to Joe user. So what I propose is this:

In OperationInterface.hpp:
-> leave hasMember for what it is, but deprecate it in the doxygen docs in
favour of hasPart():
-> add hasPart to OperationInterface.hpp which does exactly the same as
hasMember()
In Service.hpp:
-> rename hasOperation() to hasLocalOperation(). You'll need to rename them
too in ServiceRequester.cpp, Service.cpp and StateGraphParser.cpp
-> add a new function hasOperation() that returns hasPart(). Rationale: if
hasOperation() returns true, every OperationCaller object will be able to call
it (it will be a local or remote operation).

The idea is then that every mortal user uses hasOperation() and only framework
developers use hasLocalOperation() or hasPart() when they need to know if an
operation is local or remote.

>
> I add an other little patch for passing strings by reference to function of
> task context.

Thanks for your attention to detail and API review.

Peter