Oleg V. Volkov wrote:
I lean in favor of new module, because I think that it would have different approach to task. Win32API::File is low-lever "here's your access to internals, do what you want". It doesn't do any recoding or reformating (well, almost) for both input and output to make it more Perl-like, it doesn't handle Unicode or other argument errors and that's probably what it is intended to do - if someone wants quick access to API and knows exactly what he feeding there and what he gets back, Win32API::File is for him. I intend to make my module just as easy to use as normal "copy" or "move" functions from perlfunc. It will take care of checking arguments, croaking when user passes bytes instead of strings or undefined handles and will do other stuff people may not want from module that supposed to just give access to API. Another reason is that Win32API::File is partially XS and I'm not ready to mess with it just yet.
I'd like to see a mixture of high and low level features available in one nicely done module than having features scattered across various Win32::File* modules.
A word of warning about Win32::API -- the current release doesn't build on MinGW, which prevents it from working on Vanilla Perl. There's an unreleased patch, but it needs a new maintainer. See:
http://win32.perl.org/wiki/index.php?title=Vanilla_Perl_Problem_Modules for some details. Regards, David
