[cffi-devel] Re: %expand-type-to-foreign-dyn vs *runtime-translator-form*

[Stephen Compall]

On Thu, 2006-03-16 at 12:36 +0000, Luís Oliveira wrote:
> This patch fails misc-types.expand.{1,2} though since these expect
> expand-to-foreign-dyn to use expand-to-foreign. As I mentioned before, I
> kind of like that behavior. Can you convince me that it's a bad idea? :-)

Well, translate-type-to-foreign is currently used as the fallback for
expand-type-to-foreign, which is currently used as the fallback for
expand-type-to-foreign-dyn (when an e-t-f method is defined, anyway, as
demonstrated by tests 5 and 6).

However, expand-type-to-foreign has different semantics from
translate-type-to-foreign.  I highlighted this semi-issue in the most
recent patch by wrapping it in VALUES; after all, the second value,
ALLOC-PARAM, is discarded in test 6.

Since this behavior is always fine for cases where foreign-dyn expansion
isn't even tried, like setting C variables or translating callback
return values, but not for when you expect the normal free behavior from
translate-type-to-foreign in something like test 6, I think it would be
more intuitive for it to fall back directly to the translate-*
functions.  This is option 1 as described earlier, and implemented in
the latest patch.

The semantics for forms answered by expand-type-to-foreign and calls to
translate-type-to-foreign could also be unified, so that ettf forms can
also answer an ALLOC-PARAM and expect to be freed in foreign-dyn
expansion.  This is option 2, and less than ideal for some reason.

One can also specify in the interface documentation that by merely
defining an e-t-f, even if it answers *runtime-translator-form*, you are
short-circuiting the alloc-param and free mechanism for dynamic-extent
expansions, and therefore must either not do so, or always be sure to
define a foreign-dyn expansion as well.  This is option 3, the current
behavior as demonstrated by tests 5 and 6.  As this is just as arduous
as requiring an explicit call to simple-foreign-dyn-expansion (the
function presented earlier) or something if you want e-t-f semantics for
*runtime-translator-form*, but less predictable in its behavior, I would
rather it be changed.

I should note that regardless, *runtime-translator-form* can still be
eliminated in much the same way for any of the above.  Here goes:
regardless, *runtime-translator-form* can still be eliminated in much
the same way for any of the above.

-- 
Stephen Compall
http://scompall.nocandysw.com/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20060320/64333430/attachment.sig>