[Clam-devel] PATCH: new File class heirarchy

[Pau Arumi]

En/na Xavier Amatriain ha escrit:
> 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?
> 
> I agree that having the Network class explicitly show the storage format
> is bad design but I am not sure having to declare a new file class for
> anything you want to store is the way to go. I like the idea of a class
> declaring itself XMLStorable (or SDIFStorable...).

xavi, are you talking hypothetically? because this is not the 
design in clam. and i like the current storage design it let you 
do things like

Network network;
XMLStorage::Restore(network, "my.clamnetwork");

and moreover Network is not coupled with XML (look at the
interface [1]) but only with generic Storage class --though this
abstraction was not that useful as david pointed out.

1. 
http://clam.iua.upf.edu/doc/CLAM-devel-doxygen/classCLAM_1_1Network.html

i think that mixing storage and qtconfigurators matters is wrong.
the File (oh, why don't call it something like
ConfigurableFileName, please?) refactoring was (or should, imo)
restricted to the second area (qtconfigurators).
agree?

btw, i do see the need to incorporate classes like
NeuralNetworkModelFile in that hierarchie. this (unlike
EmbeddedNetworks) clearly belongs to a processing configuration.

pau


> As a matter of fact I was talking to David this morning about how the
> Acyclic Visitor pattern might help in minimizing dependencies for such a
> task: http://www.objectmentor.com/resources/articles/acv.pdf 
> 
> On Tue, 2007-04-10 at 13:48 -0700, Zach Welch wrote:
>> On Tuesday 10 April 2007 13:31, Zach Welch wrote:
>>>> 3. Should there be an EmbeddedNetworkFile?
>>> Absolutely.  In fact, I almost think it should be called NetworkFile,
>>> because it properly hides the storage mechanism.  I believe it is a poor
>>> design that exposes the fact that we store our networks with XML; this new
>>> class hides the implmentation details, and I even included my patch for
>>> NetworkEditor to re-use it to load/save its networks.
>> After sending the above message, I realized that my original patch did not 
>> actually include anything to do with EmbeddedNetworkFile. :)  The attached 
>> patch shows how the EmbeddedNetworkFile helps begin to abstract the 
>> MainWindow away from the direct use of XML.  Sorry for the confusion.
>>
>> This patch also helps underscore the ideas that 1) an intermediate NetworkFile 
>> base class could be useful (in addition to EmbeddedNetworkFile) and that 2) a 
>> NetworkStorageErr exception will be needed to completely hide the XML 
>> implementation details.  This patch works great, and it's a clear win from 
>> the perspectives of abstraction and encapsulation.  But it's not done.
>>
>> Cheers,
>>
>> Zach
>> _______________________________________________
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel