[Clam-devel] TypedControls: asking for advice and opinions

Pau Arumí parumi at iua.upf.edu
Sat Jun 28 08:51:20 PDT 2008


On ds, 2008-06-28 at 00:29 -0300, Hernán Ordiales wrote:
> On Fri, Jun 27, 2008 at 6:50 AM, Pau Arumí Albó <parumi at iua.upf.edu> wrote:
> [snip]
> > Yep! this is a conceptual problem.
> > With typed controls (or ports) the GetInControl(...) interface should
> > not be used by client classes.
> > One should only use typed controls in three ways
> >      * From within the concrete class: _myOutControl.Send(myObject);
> >      * Connecting out->in ports from two processings.
> >      * From outside the class (a client class) :
> >                OutControl<Foo> controlSender;
> >                controlSender.LinkTo( targetProcessing.GetInControl(..) );
> >                controlSernder.SendControl( foo );
> >
> >                I'm writing by heart, so not sure about the interface.
> >                LinkTo, etc.
> >                Note that the LinkTo can launch an exception -- which is
> >                something wanted.
> >
> > Does it makes sense to you?
> 
> Yep, very thanks!
> 
> But for client classes this does not add too much overhead? 3 lines of
> code when were only 1 and a bit less intuitive. And maybe a bit
> confusing, since i see the code more clear if all the outcontrol
> members are "processing's outcontrols" , if the user end up defining a
> control sender as a class member to manage the issue of sending events
> to one of its internal processings (for example to avoid the
> instantiation in every Do(), ok is not needed and could be unsuggested
> but i think many people will end up trying/doing this in a first
> approach).
> 
> cheers

I guess this use case of "getting an in port and sending a control"
happens only in Processing Composites. Which I believe are not going to
proliferate once (hopefully soon) we have Composite Networks (aka
Networks as a Processing, aka Dynamic Composites).

In those scenarios I see 4 options:

1- break encapsulation, making the concrete incontrols public. e.g.
innerProcessing.GetAmountControl().SendControl(3.0);

2- the solution I proposed before: using "private" out controls
connected to the inner in control. As you say, they should preferably be
members, and connected once.

3- hide the declaration of the private out control and the connection,
in a free function. This function should be in some general header like
Processing.hxx. An example:
SendFloatControlTo( myProcessing, 1, 3.0); 

4- Add a "backward compatibiliby" method to the Base InControl class,
like this:
innerProcessing.GetControl(1).TrySendingFloatControl(3.0)


I'd do 3:

4) makes the API dirty and promotes bad code: don't like it.
2) is a good solution, but converting existing code to this is
potentially dangerous, because we need to manage the connection life
cycle. 
3) have certain, but very small, overhead (doing the link each time) but
it is a safe transition and the user code is clean. i like this option.
1) IMO, making parent processings to know the details of its children is
a forgivable sin. But its more laborious than 3).

What do you think?
Pau





More information about the clam-devel mailing list