>
> I'd build this in userspace, but of course we don't have operator
> overloading, so the API would be a somewhat uglier function call:
It is currently possible to get operator overloads in userspace using FFI
(using my fork of lisachenko's z-engine to FFI into PHP calls). I made a
quick
I was able to get a proof of concept of the following at
https://github.com/iggyvolz/hooks:
On 3/14/2021 7:52 AM, Benjamin Eberlei wrote:
However, as functionality it could be provided as an extension first for a
proof of concept. The ingredients are all there, it doesn't need to be in
core:
On Sun, May 24, 2020 at 7:29 PM Rowan Tommins
wrote:
> In my mind error_reporting should make absolutely no difference. As you
> say, this option would be for people who don't want to interact with the
> current error system in any way, and that includes its global
> configuration state.
>
My
On Fri, May 22, 2020 at 12:56 PM Rowan Tommins
wrote:
> Personally, I'm not a fan of promoting messages to exceptions in this
> way, because APIs designed to throw exceptions generally look rather
> different from ones designed to warn and continue, so blindly converting
> seems like putting a
not have wiki karma, I have posted a draft RFC here:
https://github.com/iggyvolz/php-rfcs/blob/master/error-exceptions.txt. A
partially complete patch is linked at the bottom of the draft (very much
based off the strict_types patch).
Thanks,
Katie Volz
