[MacPerl-Toolbox] Re: [MacPerl] Mac::WASTE

[Matthias Neeracher <neeri@iis.ee.ethz.ch>]

Let's move this dicussion to MacPerl-Toolbox.

In article <19990728144836Z91897-252+34@athena.chebucto.ns.ca>, Arved_37@chebucto.ns.ca writes:
> Quoting Brian McNett <brianmc@telebyte.net>:
>> Something like this? (pulled out of WASTE.h and massaged):
>> 
>> OSErr 
>> WENew(*destRect, *viewRect, flags, *we)
>> const LongRect *destRect;
>> const LongRect *viewRect;
>> UInt32 flags;
>> WEReference *we;
>> 
>> This is doable.
>> 

> You could do worse than to tackle WENew as your first sub-project. I don't
> know for sure, but it may well be that you never need to access the fields
> of a WEReference, in which case you can sling it around as an opaque
> pointer. That being said, with this call you are nevertheless faced with
> two outputs - the OSErr and the *we reference. Do you return a 2-item
> list?

That would with very badly with the overall design of the toolbox APIs so far
(and, by the way, now would be a very good point for those who disagree with
this design to speak up :-). The principle for error codes is:

   In case of an error, store the error code into gLastMacOSError and return
   a value identifiable as an error (undef/empty list). gLastMacOSError will
   then be picked up by $^E.

In general, for each call that you want to map, try to pick an analogous call
that has been mapped already and imitate it. The WASTE API maps quite closely
to TextEdit, so try to imitate it:

WEReference
WENew(destRect, viewRect, flags)
   Rect  &destRect
   Rect  &viewRect
   UInt32 flags
   CODE:
   if (gLastMacOSError = WENew(&destRect, &viewRect, flags, &RETVAL)) {
	XSRETURN_UNDEF;
   }
   OUTPUT:
   RETVAL

>Do you set it up so you can do

> $err = WENew($destRect, $viewRect, $flags, \$we);

> and have the value of the $we variable altered?

Please don't!

>> I figured I was in for some XS code from the outset without having looked 
>> at the API, and I KNEW there was a reason for keeping a copy of SWIG 
>> handy (which I didn't :-( ).  I'll have to grab another copy at some 
>> point.

In my (limited) experience with SWIG, I found it inferior to the native
interfacing techniques of the targed VHLLs (Perl and Tcl, in my case), although
potentially easier to use.

>> My own first glance reveals the only items NOT already XS'd to be Drag 
>> Manager support 
>> <Drag.h>, and WASTE's own <LongCoords.h> (needed to support selections 
>> larger than 32K).

LongCoords should be trivial. The Drag Manager could become a bit of a drag, so
I'd leave that out in the first iteration.

> Matthias' Toolbox XS files are obvious references. You should also be
> aware that the STRUCT keyword (very useful BTW) is something peculiar to
> MacPerl XS, so you won't find it in any XS-related POD's.

Yes, although I should definitely write that up, if I weren't so busy (and a
bit reluctant to jump headfirst into the alligator pond of p5p).

Matthias

-- 
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org