[Clam-devel] Typed Controls Tests

Pau Arumí Albó parumi at iua.upf.edu
Wed Apr 30 08:52:20 PDT 2008

El dc 30 de 04 del 2008 a les 11:21 -0300, en/na Hernán Ordiales va
> On Tue, Apr 29, 2008 at 7:32 PM, Francisco Tufró <nictuku at gmail.com> wrote:
> > As explained on the Data Flow Patterns pdf sent to me by pau (and taking
> > some examples from the InPort.hxx and OutPort.hxx), i've been trying to
> > create the template classes TInControl<T> and TOutControl<T>.
> >  NOTICE: I have to say that the code i'm sending is not functional.
> > I have some problems that i'll describe here.
> >
> > 1) We have to do something with the remove link and related functions to
> > work. mLinks is not accessible from the TOutControl class (because is a
> > OutControl private member). right now i commented the mLinks occurencies
> > just to test it.
> >
> > 2) When trying to compile my test processing (TypedOutControl.hxx and cxx)
> > I get this error:
> >   TOutControl.hxx:84: error: cannot dynamic_cast 'in' (of type 'class
> > CLAM::InControl') to type 'struct CLAM::TInControl<int>' (target is not
> > pointer or reference)
> >  I don't get the key of why this is happening.
> >
> > If you think i'm going in a wrong direction on something please tell me.
> We have to have care implementing typed controls, let me first
> introduce you a bit in test driven development (even we might ending
> writing test first and the actual code then) and proceed step by step
> (with smaller goals). BTW, if you don't have one already, i recommend
> you to work with at least two sandboxes, one more general and other
> only for implementing the typed controls feature.

Totally agree. TypedControls are not trivial at all. And are core
infrastructure, thus it needs unit-testing. Starting from a copy of
current (float)Controls doesn't seem a good idea -- I think we don't
even need all the implemented features like the callback-methods
associated to incontrols.

To give an example of smaller goals that Hernan mentioned when doing
A test that connects two TypedIn/OutControl<int>, sends a 1 and checks
that it have reached the in control
Then choose the next simple goal for another test, and so on...

In TDD, you must put the simplest design that passes the test. In this
case base classes are not needed. Connection from a base class would be
a future test. 

BTW, the Ken Beck's TDD book is excellent. But there are many resources
in the web 

I think it's important to keep the TypedControls development separated
from the rest (even from MIDI) till its functionality is totally proved
and ready to integrate with processing base classe (and others maybe).
(From this perspective having separate sandboxes is not really
mandatory, but yes, can help for doing diffs and patches)

> PS: let's try to meet together with Pau at irc

Yes. Though this week will be difficult -- i plan to be off from


More information about the clam-devel mailing list