Rating abuse by the module Author is enough for me to give this module the least possible number of stars overall. (*Update*: The author has removed his rating,so I do likewise not to skew the result)
The code does roughly was it says on the box and with a few glitches it seems well documented. One of these glitches is that for the add() method the synopsis and the main documentation described to quite different usage patterns. (*Update*: The documentation is fixed)
The code looks like beginner perl and I would not be sure that the author really understands the obscurities used in the synopsis for the add() method and why it works.
The interface is directly lifted from File::HStore and therefore the author isn't the sole responsible for the interface. (*Update*: Just to clarify: This is good. There is no reason to re-invent interfaces. Reinventing interfaces unnecessary is bad. But it also means that some of my bad feelings about the interface should really be in a review of File::HStore)
My preference would be an interface where file descriptors was the main token instead of having to juggle with paths and temporary files. For File::HStore this might be reasonable as it requires access to the content of a file to generate the id.
Unless I had to replace File::HStore I would rather implement something myself. Having to deal with temporary files in my main code is just as complicated as writing the module from ground up.
But my main reason for looking at the module was the rating abuse by the original author. I havn't really tried the code...
2 out of 2 found this review helpful. Was this review helpful to you? Yes No
@Peter above, the low rating from you was well deserved. In my defence I am new here and was just trying out the ratings. I hope me setting the rating to undef will satisfy you that my intent was not ratings abuse!! I have mailed the webmaster to delete this rating.
I have fixed the documentation for add(), thanks for pointing that out!
The faulty syntax in the documentation to add() might have confused you about its usage. The add is passed File Handles to create a new File entry.I think File Handles are more appropriate than File Descriptors for use here. As for dealing with temporary files, you don't have to create a temporary file to use this module, thats the idea behind replacing Filename(The way its used in HStore) with File Handles in add(). The reason I went with FHs is to make this code suitable for use with online systems where you can get a file handle of the uploaded file which you can directly pass to add() to get your file stored on a disk with a numeric identifier. HStore internally gets a handle from the filename that is passed to it anyway, so why force a program which has only got a filehandle from its source, to write a temporary file to get a filename for add()?? on the other hand if the user has access to a file name he can still create the file handle and pass it to add().
I think using file handle instead of filename is much cleaner for this interface.
As for borrowing from HStore, it is explicitly mentioned in the perldoc along with credits to the author of HStore that this module is based out of HStore, I had a e-mail discussion with Alexandre(author of HStore) about my plan to write this module and about the changes I planned for the interface to this module compared to HStore, before I set out to write this module.
1 out of 3 found this review helpful. Was this review helpful to you? Yes No