[Clam-devel] PATCH: new File class heirarchy

[Xavier Amatriain]

No, no. I wasn't saying that needs to be solved "before" the patch, I
just pointed to the underlying and longer term discussion. Actually, my
previous email (talking about the three issues) was precisely in that
direction: my vote is for accepting the patch as is and discuss on the
other issues in parallel.

On Tue, 2007-04-10 at 15:50 -0700, Zach Welch wrote:
> On Tuesday 10 April 2007 14:28, Xavier Amatriain wrote:
> > Thanks Zach, I think your patch points to an underlying question that is
> > difficult to answer right away:
> >
> > Do we want the File hierarchy to just depend on the format and not the
> > content being stored? Or, like you propose, do we want it to depend on
> > what's being Stored and not the format?
> 
> Does this need to be answered before this patch is committed?  Why not accept 
> the patch and let me continue to evolve things?  We can change the design 
> later to meet future requirements or expections, but it gives immediate wins 
> in NetworkEditor (or any program that wants to write generic functions for 
> prompting the user to select audio input or output files).  
> 
> I considered additional changes that would have provided some answers for your 
> questions, but I did not implement them because I recognize that they can be 
> added later.  Given that I can incrementally address issues through future 
> patches, I would like to focus on reasons why it should rejected outright in 
> its original form.  I believe that I have addressed the immediate objections.
> 
> David said on IRC that, in general, the word "eventually" was banned from 
> design discussions, since it can cause more complexity that it eliminates.  
> If things need to be evolved because of changing requirements, the code can 
> change when the specific eventuallity arises.  In this way, I do not want to 
> get caught up in abstract discussions about what might be best in the future; 
> I want to focus on concrete benefits or problems from the present changes.
> 
> My next steps might be to address the in-tree SDIFFile and MIDIFile classes, 
> bringing further abstraction through refactoring.  I can begin to rewrite my 
> EmbeddedNetworkFile and NeuralNetworkFile classes, evolving the best design 
> from actual use cases.  But my patch brings good things today, and provides a 
> foundation for work that I have in progress.  Returning to the key question: 
> what is wrong with my patch that prevents its immediate addition to the tree?  
> 
> Cheers,
> 
> Zach
> 
> _______________________________________________
> 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       *
 ********************************/