[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

Re: Newer xsubpp



On Sun, Jan 23, 2000 at 12:48:57PM -0500, Ilya Zakharevich wrote:
> On Sun, Jan 23, 2000 at 10:30:36AM +0000, Tim Bunce wrote:
> > > Since this looks like just syntactic sugar over what XS already
> > > provides, it may be worth writing this as a preprocessor that emits
> > > the equivalent XS code.
> > 
> > I'm really not very comfortable with pure out values being specified in
> > the prototype. It's unnatural and ambiguous. Bound to cause confusion.
> > They should be specified elsewhere.
> 
> One should think of the prototype as of the description of C API.  You
> probably think of it as of the description of Perl API.  [This
> difference - as many others - is not stressed out in xsubpp documentation.]
> 
> Think of prior art too.  Think IDL.

I don't think so. But perhaps that's because I don't "think IDL".

Simply put, I'd read:

	int
	foo( in int x, out int y )

as needing to be called

	foo( $x, \$y )     [or as foo( $x, $y ) "pass by alias" etc]

I recently implemented a Perl API to a C++ library that had lots of
"out" and "inout" parameters. I chose to use "pass by alias" (for want
of a better name) and thus the Perl API looked _exactly_ like the C++
one to the point of being able to use the same documentation.

It would have been very 'unnatural' and unwieldy in this case to have a
bunch of out parameters returned as a list along with the method return
status. Updating the arguments 'in place' made the API very neat and
simple to use.

I guess my point, now I've thought about it some more, is that three
forms of "out" should be provided with unambiguous names.

One meaning "return this value via the 'result' of the function",
another meaning "return this value by updating the dereferenced argument",
and a third meaning "return this value by updating the argument directly".

Perhaps:
	out_by_result
	out_by_ref
	out_by_alias

Even if you don't want to go that far, I believe that "out" by itself
is too ambiguous.

Tim.


Follow-Ups from:
Ilya Zakharevich <ilya@math.ohio-state.edu>
References to:
Ilya Zakharevich <ilya@math.ohio-state.edu>
Gurusamy Sarathy <gsar@ActiveState.com>
Tim Bunce <Tim.Bunce@ig.co.uk>
Ilya Zakharevich <ilya@math.ohio-state.edu>

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]