I discovered that using convert_to_(string|unicode)_with_converter()
on objects still used runtime encoding instead of the specified
converter. Turns out it's because cast_object handler has no clue
about the converter passed to the macro. This patch implements a fix
via adding an extra generic pointer parameter to cast_object that can
be used by various types as necessary. If no one objects, I'll commit
the change soon.
-Andrei
I discovered that using convert_to_(string|unicode)_with_converter()
on objects still used runtime encoding instead of the specified
converter. Turns out it's because cast_object handler has no clue
about the converter passed to the macro. This patch implements a fix
via adding an extra generic pointer parameter to cast_object that can
be used by various types as necessary. If no one objects, I'll commit
the change soon.
How does this impact userspace __toString() handlers? Would we pass the
encoding from the converter to them?
function __toString($encoding) { }
Do we need __toUnicode($encoding) as well?
Would we just let the user pass back whatever type then convert as needed
in the internal cast handler?
-Sara
How does this impact userspace __toString() handlers? Would we
pass the
encoding from the converter to them?function __toString($encoding) { }
Do we need __toUnicode($encoding) as well?Would we just let the user pass back whatever type then convert
as needed
in the internal cast handler?
Right, I was thinking that they would just return Unicode or binary
strings and the standard object handler takes care of converting it.
That's the way it's currently implemented.
-Andrei