Hi internals,
We have a long-standing issue (tracked at
https://bugs.php.net/bug.php?id=64196 and the very numerous duplicates)
that certain types of infinite recursion can lead to a stack overflow.
While for us it is easy to diagnose this, end users will only see a
"segmentation fault" and will b
> On 3 Feb 2020, at 14:29, Nikita Popov wrote:
>
> Hi internals,
>
> We have a long-standing issue (tracked at
> https://bugs.php.net/bug.php?id=64196 and the very numerous duplicates)
> that certain types of infinite recursion can lead to a stack overflow.
> While for us it is easy to diagnos
Hey folks.
During the last year I took a bit of time aside to bring the
documentation from SVN to git. And about a month ago I informed the
DOCs-Mailinglist about the current status and the fact that we are ready
to move to the next step[1]. Now some tasks need to be done by people
with appropriat
As you know we have __toString method that runs whenever an object is
typecasted to string or it is directly echoed.
'value'
];
}
});
$casted = (array)$class;
print_r($casted);
/*
prints:
Array
(
[key] => value
)
mahmut
*/
What would you think? I think it would add value.
Or we can deprecate __toString() method at all and detect cast events
instead. Would it make more sense? Something like this __casted().
P.S: I saw the previous conversation but hence now we have types, it would
make sense.
Midori
On Tue, 4 Feb 2020 at 08:15, Midori Koçak wrote:
> As you know
>
> So the main question is now, how the PHP-Project wants to go on with
> moving the documentation from SVN to git? Is there any interest in
> continuing this project?
Yes please. I would contribute a thousand times more if I could just make
PRs on GitHub.
Right now I'm being put off by the docu
Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the
status of this?
On Tue, 4 Feb 2020 at 08:18, Midori Koçak wrote:
> Or we can deprecate __toString() method at all and detect cast events
> instead. Would it make more sense? Something like this __casted().
>
> P.S: I saw the p
Hey all.
Instead of adding more magic I personally like the approach of
explicitness more and your suggest adding an interface "Arrayable"
(naming is hard and this might not be the best name) instead. Whether
that interface then defines a `__toArray()`-method or something entirely
different is the
