[Clam-devel] PATCH: new File class heirarchy

[Pau Arumi]

En/na Zach Welch ha escrit:
> Hi all,
> 
> The attached patch refactors the re-usable portions out of the AudioFile class 
> and into a new File class.  This new base class contains virtual methods that 
> allowed further refactoring of the GUI configurator to use one pair of 
> methods to operate on the different types of files.  These changes will help 
> eliminate redundant code in the EmbeddedNetworkFile and NeuralNetworkFile 
> classes that I have in my tree, as well as hypotheticals like VideoFile.
> 
> This patch also changes the semantics of AudioFile, AudioFileSource, and 
> AudioFileTarget; inheriting from File, AudioFile has become an abstract base 
> class and can no longer be instantiated.  Changes are included to make all 
> in-tree consumers use either AudioFileSource (for reading) or AudioFileTarget 
> (for writing).  These differences are all fairly minor, but they have one 
> positive side-effect: they help clarify the intent of the surrounding code.
> 

i need some explanation on why a File base class pays off. in 
case it's worth, i'd need to think the best location since 
src/Standard is the place for non-clam-specific code.

for example, in what situations is this File interface used?
	virtual const char* GetClassName() const = 0;
	virtual const char *GetGroupName() const = 0;
	virtual const char *GetPromptString() const = 0;

i guess the bottom line here is that a separated base class is
useful for your EmbeddedNetworkFile, but in the first place i
don't see why we need such EmbeddedNetworkFile class. we already
have XMLStorage that can save/restore networks, and in my view
-as recently showed in the api proposal- is the network who
should manage it's sub-networks not a processing that is
configured with a filename.

we need to keep discussing the sub-networks design if you're
implementing it. this is not a lateral thing but something
very in the heart of the framework!

and yes, proof-of-concept patches help but... the smaller the
better :-)

thanks again for your work, zach!
pau