Note to Win32 Perl Programmers

djberg96 on 2003-10-30T04:39:59

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?

---

Not sure of my Latin...

jhi on 2003-10-30T09:10:57

> Why are people coding this way?

Brainrottus Redmondus?

Different culture

jjohn on 2003-10-31T02:16:20

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 nearly stopped bleeding. Is unix quirky? Sure it is, but somehow it seems like it wasn't designed with quite the same level of butt-monkeyness that prevades win32.

I haven't programmed in MVS yet, although I suspect MVS makes Win32 look positively unixy. ;-)

Re:Different culture

pudge on 2003-11-11T15:36:00

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), 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 or () and the error code is available in the $^E variable.

          $port = GetPort();
          SetPort($port);
          $desc = AECreateDesc("TEXT", "Hello, World") or die $^E;

• Complex data structures are mapped into blessed references. Data fields are available through member functions which return the value of a field if called without an argument and change the value if called with an argument.

          $rect = Rect->new(10, 20, 110, 220);
          $rect->top;
          $rect->right(250);

The Mac OS culture is/was about as different from the Perl culture as the Win32 culture, but it can be made to work, without too much difficulty.

Re:Different culture

pudge on 2003-11-11T15:38:56

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.