[Clam-devel] PATCH: new File class heirarchy

[David García Garzón]

On Dimarts 10 Abril 2007, 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

I thought you were more on converting AudioFile in a Filename than Filename in 
a AudioFile. I mean is good having the extensions for any given file type 
available on the configurator, but abstracting an std::fstream is too much. 
AudioFile could be an exception because we wanted to wrap 
libsndfile/libmad/liboggvorbis... but extending AudioFile complexity to 
others that don't need that is not the proper way.

Hiding the details of the XML implementation!?? Oh men, don't ask how much 
abstracted is that implementation nowadays... do you really need to put 
another layer on the top? No, seriously, why i don't want to get the XML 
error at the user interface level. I want to! Do you really want to store a 
network in something else than XML? Really? if you do, why do you want to 
hide that? Do you want to store the file in somewhere else than a file? Then 
you can pass any stream: memory, sockets...

I spent a lot of time figuring out how to implement a generic storage for XML, 
SDIF, or whatever, and i did a lot of overdesign for 'exentual' (do you 
remember the word? ;-) ) formats that may appear. All that over design is 
going to the same place flkt and qt3 classes went because now nobody is using 
it, and that means arround 8 classes drop (base Storage and the Adapters) and 
a nice simplification of the XML format customization. If you have a new 
format to support, tell me and i won't drop that, although i assure you i 
want to ;-)

Just check the usage code: one line more, one more intermediate object which 
really hides useful information and adds information totally useless, for a 
code reader point of view, it is just a filename, i am loading, so why the 
object? Pass it the fuzzing string.

Well, i should take a closer look for your patch. Not now. I still must finish 
my homeworks. Exentually.

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
(Home) vokimon at telefonica adot net
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070411/8bf6c19c/attachment-0001.sig>