On 2006-mar-13, at 18:48, Stephen Compall wrote:
Surely we want free-translated-object to be called in this case.
It will be. The problem appears in the current rules for providing a
fallback when expand-to-foreign-dyn is not provided. This is
exemplified in the new tests: one answers T and the other answers NIL,
when both should answer T or NIL.
Judging from the comment in misc-types.expand.6 I thought you did
want it to return nil.
According to node "Optimizing Type Translators", several forms are
guaranteed to use `expand-type-to-foreign' even when they want the
semantics of foreign-dyn expansion, when such an explicit expansion is
unavailable.
I think this is useful.
3) Specify that the form answered by expand-type-to-foreign, when
evaluated, answers a value that does not need to be freed. This is
currently implemented by not providing a foreign-dyn expansion method,
in the case of foreign-typedefs anyway.
This was what I had in mind.
This does not preclude providing a function to trivialize
overriding the
default behavior in favor of option 3, if the type-defining user so
chooses.
(defun simple-foreign-dyn-expansion (value var body typename)
"Answer a form to be answered from `expand-to-foreign-dyn',
where VALUE, VAR, BODY, and TYPENAME are the respective args to
the aforementioned GF. The result will not be freed."
`(let ((,var ,(expand-type-to-foreign value (parse-type typename))))
,@body))
I guess that picking option 1 or 3 is a matter of picking the best
default behavior. Isn't option 3 the most common case?
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
