One important note here. This patch will change cast behaviour in case of
local and foreign types are mismatched.
The problem is if we cannot convert types locally, this does not mean that
it is also true for a foreign wrapped data.
In any case, it's up to the committer to decide whether this chang
So, patch looks good to me. Implements described functionality. Test case
also provided.
I think it's ready to be viewed by a committer.
--
Best regards,
Maxim Orlov.
On Mon, 27 Jan 2025 at 09:46, Alexander Pyhalov
wrote:
> Unfortunately, it's not so simple. We can't just ship type casts to
> remote server if we are not sure that local and remote types match. For
> example,
>
Yeah, my fault. I've overlooked an "elemexpr" member in "ArrayCoerceExpr"
and errone
Maxim Orlov писал(а) 2025-01-24 18:09:
Look like an overlook for me. Apparently no one has encountered this
use case before.
Patch seems good to me with no visible defects. Deparse support was
also added. As well as a
test case. But do we really need copy/paste code for a
T_ArrayCoerceExpr case?
Look like an overlook for me. Apparently no one has encountered this use
case before.
Patch seems good to me with no visible defects. Deparse support was also
added. As well as a
test case. But do we really need copy/paste code for a T_ArrayCoerceExpr
case? To be more specific,
can we "reuse" T_Re
