Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Wednesday October 29, 2003
11:39 PM

Note to Win32 Perl Programmers

[ #15469 ]
To the Win32 Perl programmers out there submitting modules to CPAN: stop translating the Win32 API into Perl and give me a nice interface.

Case in point: Win32::DirSize (which I'm picking on because a new release just came out). Here's a brief synopsis:

my $Directory = "C:\\TEMP";
my $DirInfo;
my $Result = dir_size(
   $Directory,
   $DirInfo,
);
if ($Result == DS_RESULT_OK) {
   my $Unit;
...

This bit from the synopsis shows two examples of what I mean. First, it uses predeclared variables that act like buffers ($DirInfo in the above example), which is very C-like and not very Perl-like. I don't mind it in C but it annoys me in Perl. Second, it exports Win32 error code constants from the API and forces ME to check the return value - ugh. Failure ought to be handled internally with $! set to the appropriate error message.

To be sure, Win32::DirSize is not the only guilty party. In fact, it seems that most of libwin32 is like this.

Why are people coding this way?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Note to Win32 Perl Programmers 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > Why are people coding this way?

    Brainrottus Redmondus?

  • Those that work on win32 must bend their minds to the environment. Win32 wasn't designed for programmers like unix was. Win32 is about pain. Win32 is about making Suits happy. Win32 is about keeping the riff-raff from writing their own applications instead of buying them. It's about making sure the lowest common demoninator macro writer doesn't hose the system (this goal hasn't been met with all that much success).

    Recently, I've had some new adventures in OLE programming and already my eyes have nearl

    • Yeah, but different culture is no excuse. When Matthias did the mappings for Mac OS for MacPerl (now a part of Mac::Carbon, and I copied over his strategy into the Mac::Carbon docs [macperl.org]), he made these two design decisions:
      • MacPerl toolbox calls take their input arguments in the same order as the corresponding toolbox functions. Output arguments are never passed by reference, but returned from the calls. If there are several output arguments, a list is returned. If an error occurs, the function returns undef
      • BTW, there is also another issue, which is having a Perl API on top of the C API. That is, instead of:
        $desc = AECreateDesc("TEXT", "Hello, World") or die $^E;
        You can also do:
        $desc = AEDesc->new("TEXT", "Hello, World") or die $^E;
        And it gets even more simplified with things like Mac::AppleEvents::Simple, which takes several calls to various Mac::AppleEvents functions and wraps them into single calls.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.