[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

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



On 29 Jul 1999, Matthias Neeracher wrote:

> In article <19990727185703Z91893-253+24@athena.chebucto.ns.ca>, Arved_37@chebucto.ns.ca writes:
> > If I may offer a few words of advice.
> 
> You advice was very interesting to read, as it pointed out to me how badly I
> have really documented my techniques for interfacing. So here's an attempt to
> do so:
> 
> >Copy and paste the WASTE public API
> > into a fresh file, and lay the functions out K&R C style, that is:
> 
> The end result is correct, but I'd recommend strongly against that
> process.
[ Description of process snipped ]

Guess what I'll be looking at and studying this evening? :-)

I assume you're *strongly* recommending against the manual method I 
suggested because you've already invented the better way, not because it's
intrinsically bad? I suppose it comes as no surprise - a lot of Toolbox XS
has been done, C::Scan on MacOS doesn't work basically, and I can't see
you doing my procedure for every call that's been converted so far.

> 
> > Identify the arguments as IN, OUT, or INOUT (leave the IN's blank if you
> > like). OUT's and INOUT's will require special treatment - hopefully there
> > won't be too many of them.
> 
> My philosophy for Toolbox API ports so far has been to have *NO* out
> parameters. No exceptions. I believe that out parameters fit badly into
> the perl design.
>

Fair enough. So the rule of thumb is to return multiple outputs in a list?

Conventions are good things. And I agree, OUT and INOUT parameters are
un-Perlish.
 
> > Identify all the complex datatypes that need to be accessed *from* Perl,
> > either for reading fields or setting fields. These have to be done in
> > more detail;
> 
> Yes, using the ext/Mac/ExtUtils/ExtractFields script.
> 
> >the others, that are still going to be passed around in Perl,
> > can be handled as "opaque" pointers.
> 
> Yes.
> 
Matthias, it seems like a POD concerning MacXS might be in order. *My*
tutorial assumes knowledge of XS, and takes it from there, but these Mac
specific procedures are well worth documenting.

Foremost, though, if there are XS conventions that you want to have
followed, and I think that conventions make sense, possibly you could put
some thought into putting them into same POD?

Regards, Arved



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