|
From: Ivan V. i B. <iv...@ca...> - 2004-11-18 15:07:55
|
Hi all! On the process of adding write support (overwriting, not
appending, 'r+') support to tables.nodes.FileNode, I have come across
a difficulty with the splitting between newNode() and openNode(). In
the beginning, it seemed a good idea, since the kind of objects passed
as arguments were quite different (h5file and creation arguments in
the first function, only node and mode in the second one). However,
the possibility of creating a new file node in either append or write
mode would make necessary the addition of a 'mode' argument. It would
be fairly easy to add a second 'mode =3D 'x'' argument to newNode(),
which would not break interface compatibility. Semantic compatibility
would imply 'x' being 'a+'.
However, I have pondered adding suport for 'w', 'a' and 'w+' modes
in addition to the supported 'r' and 'a+', and the mentioned 'r+'.
Right now, RWFileNode.__init__() does all node creation tasks (with an
admittedly ugly argument list treatment). The addition of those new
modes would imply more cases of node creation, as well as some cases
of node replacement or emptying. This would complicate __init__()
methods for the new classes.
To avoid the problem of __init__() diversity of arguments and
implementation complexity, I have considered moving all node creation
and emptying to newNode() and openNode(). In this way, new classes
would only have to handle existent nodes. Using some mix-in classes
for readable, writable and appendable behaviours of the file methods,
FileNode classes would be fairly simple to implement. New classes
should not cause compatibility problems, since they keep the same file
interface, and the current __init__() methods for the current FileNode
classes should not have been used directly (in theory).
However, moving node creation to newNode() and openNode() would
most probably cause duplicate behaviour. Both functions should end
up calling a same function. In this way I have got to the idea of
dumping newNode() and using a new definition of openNode (in a similar
way as file() or open()). The new signature would be:
openNode(h5file, path, mode =3D 'r', title =3D '',
filters =3D None, expectedsize =3D None)
By taking out arguments only related to FileNode, the signature
could be reduced to:
openNode(h5file, path, title =3D '', options =3D FileNodeOptions())
Where 'path' would be the full, absolute path of the (maybe new) node.
This signature could be shared with future tables.nodes subpackages
(of course, changing the default value for 'options'). XXXOptions
would be a simple container object for node-dependent options ('mode',
'filters' and 'expectedsize' for a FileNode object). If name clashing
was preferred to be avoided, the function could be named
openFileNode() for the FileNode object. In any case, a new function
tables.nodes.openNode() could be used to open eny kind of *existing*
node defined in tables.nodes, by mapping its '_type' attribute to its
opening function.
There is also the question of emptying or replacing the node of
the file when truncating ('w', 'a' and 'w+'). Is replacing the node
with a new one a valid solution? Emptying the file without replacing
it is not possible right now, since EArray objects can not be
truncated (ummm, this would be a _very_ useful addition!)
Sorry for the long message. It also helped me to sort some things
out. So, what's your opinion on the new openNode() function and the
truncation issue?
Thank you,
Ivan
=66rom ivan.opinion import disclaimer
--=20
Ivan Vilata i Balaguer >qo< http://www.carabos.com/
C=E1rabos Coop. V V Enjoy Data
""
|