Removing Names from Configs

What's Wrong?

It introduces a lot of complexity in Processing base class --specially in Configure-- because the parent (Composite) have to check if Name dynamic attribute is set and if it's repeated in its scope (the parent composite).

Client code is unclear: because configuration have the Name attribute the user don't use in any way. Morover, while some examples configure the name, others (most) don't.

Identifying by string not-in-network Processings is an unneeded feature (and thus, overcomplexity). Some reasons:

• Processing objects inside a composite are identified directly by its processing composite attribute. So in this case we don't need a string identifier
• Free (not composite leaves) processing objects are also identifyed directly through a (C++) variable
• in-network processings are string identified but in this case we want the holder of the identifier to be the network object, and not the top level composite. So we want to do:

  	network.addProcessing("LFO", new Oscillator);
  	network.addProcessing("ToneGenerator", new Oscillator);

  and configurate them afterwards (using a generic interface --aka: network editor). Actually, the interesting way of adding processings into the network is passing the identifier and the class name, deferring the creation to the processing factory.
  
  One could argue that in networks we could use the config name to identify the processing object inside the network but it's not possible because one of the goals of the network is to treat processings generically (not knowing its concrete type in advance). In such cases we cannot configure processings before adding them to the network. Summing up: having config-name in networks is of not usefull at all.

So why did we put them into the configuration? I remember the (long ago) decision of doing this mostly because we wanted see named objects in the forseen introspection tool.

I'm of the opinion that this use case (introspection) can be perfectly archieved knowing only the class name (Processings have a mandatory GetClassName()): if it happens to be lots of objects with the same class name is no big deal since the introspection tools will show anyway the topology (network) of the system which will desambiguate which processing is which. Morover I think those kind of tool is much more likely to be made for networks than for non-network environments.

Proposed Solution

Remove the Name attribute in configs. More concretelly:

• Remove the virtual GetName() in Config base class
• Remove the DT attribute Name in each concrete config class. I mean concrete classes inside CLAM.
• Remove the AddName from most of DefaultInit's methods
• Remove most of the code in Configure(...), and its helper methods (InsertAndGiveName and co.) Not few lines of code!

Backward compatibility

Fortunatelly leaving the concrete config classes with the Name attribute should be no problem at all. (well, leaving apart the problem of having unused code. )

How to make the transition in client code?

Though leaving Name attributes in client code won't hurt, I'm of the opinion of making a quick transition and remove those blank implementation asap. As is

A trivial script could be provided that signals all the lines that should be removed.