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

[Hernán Ordiales]

On Sat, Jun 28, 2008 at 12:51 PM, Pau Arumí <parumi at iua.upf.edu> wrote:
> 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]
> 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?

I like 3 too

-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9