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.