[Clam-devel] PATCH: new File class heirarchy

[Xavier Amatriain]

Pau, all, I think there are at least 3 separate issues that need to be
discussed independently:

1. Is there a need to refactor into a new File class?

My answer to this would be a clear Yes and I think that Zach's patch is 
in the right direction. We now have quite a mess of a File Hierarchy
(note for instance SDIFFile or MIDIFile) that should benefit from having
such a base class.

2. Could the File class interface be improved?

Obviously yes. As Pau pointed out there seem to be some interface
methods that are at least questionable. Zach, could you give more
feedback on why and how those methods should be required?

3. Should there be an EmbeddedNetworkFile?

And here my answer probably goes with Pau, in the sense that there is no
reason to have such a file class when we have the storable in place.

So I would be for accepting the File patch if there is some
discussion/justification on its interface (keeping it as minimal as
possible if there is no clear agreement). That could then be used to
refactor other file-related stuff in CLAM.

And, in a separate thread, we could discuss the subnetworks (or
supranetworks, or composite networks, or embedded... we probably even
have to discuss on how they should be called ;)

XA

On Tue, 2007-04-10 at 17:36 +0200, Pau Arumi wrote:
> 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
> 
> 
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
-- 
/*********************************
 *       Xavier Amatriain        *
 *  Associate Director - MATi    *
 *  Research Director - CREATE   *
 *    UCSB, Santa Barbara CA     *
 *      1-(805)- 893 83 52       *
 ********************************/