[clam-devel] Simplifying DynamicTypes

David García Garzón david.garcia at barcelonamedia.org
Mon Jul 18 08:03:42 PDT 2011


I got an amusing rainy sunday i spent refactoring the DynamicType class.

There is a never merged DT-Inheritance branch. The problem it requires a lot 
of user code refactor because it changed interface and the branch got quite 
old waiting the time to merge. So I am taking the approach of simplifying the 
current code instead by removing a lot of unused over-design.

Many unused protected accessors were removed (were thought to be used by 
CLAM::Branches but they never came to existance). At the end just the high 
level interface is available outside the DT class (so i had more freedom to 
hack it). Also any public or protected data is now private.

I renamed the IsAttributeInstantiated(i) into HasAttribute(i). So the generic 
interface has became: HasAttribute(i) AddAttribute(i) RemoveAttribute(i)
Which is quite parallel to the HasX, AddX, RemoveX, interface provided by the 
DT macros on concrete dtypes. Tested and it doesn't conflict with and 
attribute named "Attribute" (Generic interface is hidden under the regular one 
but you DON'T want to use the generic interface if you have the concrete one 
available)

The global flags that hold that some attribute has been added or removed were 
hard to maintain (needed a loop). A more convenient _attributesNeedingUpdate 
member is used for that.

The _dataSize was computed accomulatively every time we add or remove an 
attribute. This leads to a possible inconsistence and it is used just once on 
UpdateData. Now it is computed in UpdateData and i removed the member.

Last but not least important. It seems like nobody in clam-project 
repositories used the 'shared' and 'deep' copy constructor flags so that meant 
that the SharedCopy and ShallowCopy (by default deep=true) are not used at all 
and thus we can remove a lot of complexity.

If your code used Shared or Shallow copies give us a warning (i would suggest 
using pointers instead, but it depends on the case). Also if you implemented 
some intermediate class (like ProcessintConfig, ProcessingData...) they need 
to remove those extra parameters to the copy constructor.

Many small refactors were done to clearify the code. I was passing the tests 
but anyway beware the bugs.

David.




More information about the clam-devel mailing list