Re: [PHP-DEV] Re: What about a magic __toArray() method?
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 then a different matter.
Additionally this would be in line with Nicolas RFC regarding
"Stringable" (https://wiki.php.net/rfc/stringable)
Just my 0.02€
Cheers
Andreas
Am 04.02.20 um 08:18 schrieb Midori Koçak:
> 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 we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>> public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>> }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>> public function __toArray(){
>> echo "casted\n";
>> return
>> [
>> 'key'=>'value'
>> ];
>> }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] Re: What about a magic __toArray() method?
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 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 we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>> public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>> }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>> public function __toArray(){
>> echo "casted\n";
>> return
>> [
>> 'key'=>'value'
>> ];
>> }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>
Re: [PHP-DEV] Moving the documentation to git
> > 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 documentation editor. — Benjamin
[PHP-DEV] Re: What about a magic __toArray() method?
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 we have __toString method that runs whenever an object is
> typecasted to string or it is directly echoed.
>
>
> $class = (new class{
> public function __toString(){
> echo "casted\n";
> return "mahmut\n";
> }
> });
>
> echo $class;
> $casted = (string)$class;
>
> /*
> prints:
> casted
> mahmut
> casted
> mahmut
> */
>
>
> As you know toArray() method implemented when an object is converted into
> and array and most of the time when a plain data object is sent to
> front-end.
>
> Having a magic method like __toString called __toArray would be useful to
> detect and act on conversion events.
>
> Roughly it would be like:
>
>
> $class = (new class{
> public function __toArray(){
> echo "casted\n";
> return
> [
> 'key'=>'value'
> ];
> }
> });
>
>
> $casted = (array)$class;
> print_r($casted);
>
> /*
> prints:
> Array
> (
> [key] => value
> )
> mahmut
> */
>
> What would you think? I think it would add value.
>
[PHP-DEV] What about a magic __toArray() method?
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.
[PHP-DEV] Moving the documentation to git
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 appropriate karma to be able to get on with the whole thing, but all the background tasks are done and awaiting further processing. Sadly there was no response so far. Neither on the email as such nor on the different tasks. 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? And if so, who can either take on the necessary steps or provide us with the appropriate credentials and access rights that we can do them ourselves? Thanks for reading and looking forward to the results. Cheers Andreas [https://news-web.php.net/php.doc/969387429] -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] VM reentry limit
> 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 diagnose this, end users will only see a > "segmentation fault" and will be unable to correlate this with infinite > recursion as the root cause. > > To provide some technical context, recursion in PHP usually occurs on the > virtual machine stack, in which case unbounded recursion is supported, as > long as the stack size does not exceed your memory limit. However, some > types of calls (in particular magic methods and certain callbacks) go > through an internal function and have to reenter the virtual machine. This > uses up space on the C stack and may ultimately result in a stack overflow. > > I would like to propose the introduction of a zend.vm_reentry_limit ini > option as a solution to this problem, implemented in > https://github.com/php/php-src/pull/5135. This ini setting will limit the > number of nested VM reentries that are allowed before an Error is thrown. > > It should be noted that this is (intentionally) not a general recursion > limit. Deep recursion can happen legitimately (e.g. during AST processing) > and it is hard to put a reasonable upper limit on it that both detects > unintentional infinite recursion while allowing legitimate deep recursion. > The limit implemented here exists specifically to prevent stack overflows > and give the programmer a more obvious indication of the cause of the > problem. > > Regards, > Nikita > > PS: Some extensions will force all function calls to occur via VM reentry. > Such extensions should probably either disable the option (by setting it to > -1), or significantly increase the limit, to avoid false positives. I would love to see this addition, I think it can be really helpful for a lot of users. Can we add a function to report the number of VM reentries as well (get_vm_reentry_count). This could be helpful for determining a reasonable ini value. Cheers, Ruud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VM reentry limit
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 be unable to correlate this with infinite recursion as the root cause. To provide some technical context, recursion in PHP usually occurs on the virtual machine stack, in which case unbounded recursion is supported, as long as the stack size does not exceed your memory limit. However, some types of calls (in particular magic methods and certain callbacks) go through an internal function and have to reenter the virtual machine. This uses up space on the C stack and may ultimately result in a stack overflow. I would like to propose the introduction of a zend.vm_reentry_limit ini option as a solution to this problem, implemented in https://github.com/php/php-src/pull/5135. This ini setting will limit the number of nested VM reentries that are allowed before an Error is thrown. It should be noted that this is (intentionally) not a general recursion limit. Deep recursion can happen legitimately (e.g. during AST processing) and it is hard to put a reasonable upper limit on it that both detects unintentional infinite recursion while allowing legitimate deep recursion. The limit implemented here exists specifically to prevent stack overflows and give the programmer a more obvious indication of the cause of the problem. Regards, Nikita PS: Some extensions will force all function calls to occur via VM reentry. Such extensions should probably either disable the option (by setting it to -1), or significantly increase the limit, to avoid false positives.
