Just as in the previous point, we have seen that most Processing Data
classes offer a too complex interface.
- Making Dynamic only what needs to be Dynamic. Dynamic Types 3.2.2
have proven as a very useful mechanism and they offer many interesting
services (such as automatic XML storage, homogeneous interface...)
but its usage needs to be rationalized. The dynamic mechanism for
adding and removing attributes at run-time is sometimes more annoying
than useful. The overhead introduced by having the possibility of
instantiating and de-instantiating attributes on run-time, for example,
is seldom needed. On the other hand, some limitations in the Dynamic
Types Structure, such as not being able to use inheritance, have already
been solved and a new, improved version of these service is already
developed. The problem is that introducing this change will break
backward version compatibility in many ways, so the right moment is
still to be chosen. The goal is to identify when and where DT are
strictly necessary and only use them there.
- In some Processing Data classes it would be interesting to have inheritance
capabilities. This is now limited because of the use of DT. The changes
in Dynamic Types will clearly affect the way that CLAM Processing
Data are structured in some ways. The fact that inheritance is introduced
into Dynamic Types, and therefore into Processing Data, opens up the
possibility of implementing a Processing Data hierarchy.
- Clarifying the use of the Spectrum class. The Spectrum class is very
flexible but also too complex. Also by making some conversions transparent
it is hiding from the user the fact that some practices are not efficient
and should not be done inside a Do() operation. We may need to offer
specialized spectrums which are efficient and explicit while keeping
the current interface as a wrapper only to use in particular cases.
- To dB or not to dB. The use of linear/dB magnitudes in CLAM is not
well solved so we need to devise a mechanism for taking care of this
issue. This solution should aim at being both transparent and efficient.
2004-10-18
