RE: [PHP-DEV] Re: [VOTE] Userspace operator overloading
On Thursday, March 26, 2020 6:19 PM Guilliam Xavier wrote: >> If the concat operator is not overloaded, the behavior is like now, and the >> objects are converted implicitly to strings (so $a . $b actually means >> (string) $a . (string) $b). >> Furthermore an notice is triggered, hinting the user that he could overload >> the concat operator. (Maybe here a different message than for the other >> operators would be useful). > > I fear that "hint" notice could break Symfony apps... Couldn't you just not > trigger it in this case? Yes this would be possible and I think that it might be reasonable to omit the notice in this case (maybe only if the objects really implement a __toString). What do others think about this? Regards, Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading
On 26.03.2020 at 18:18, Guilliam Xavier wrote: > On Thu, Mar 26, 2020 at 5:37 PM wrote: >> >> The overloaded concat operator has higher priority than the __toString() >> method. >> So if Class A overloades the concat operator, then calling $a . $b means >> ClassA::__concat($a, $b); (Note that both operands are passed in their >> original form) >> If you want to concat the string representations, you will have to >> explicitly convert the objects to strings: >> $ret = (string) $a . (string) $b; > > This first part seems legit to me. > >> If the concat operator is not overloaded, the behavior is like now, and the >> objects are converted implicitly to strings (so $a . $b actually means >> (string) $a . (string) $b). >> Furthermore an notice is triggered, hinting the user that he could overload >> the concat operator. (Maybe here a different message than for the other >> operators would be useful). > > I fear that "hint" notice could break Symfony apps... Couldn't you > just not trigger it in this case? Either that (it's what I would prefer), or clearly document that BC break (even if it's just about a notice). Thanks, Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading
On Thu, Mar 26, 2020 at 5:37 PM wrote: > > The overloaded concat operator has higher priority than the __toString() > method. > So if Class A overloades the concat operator, then calling $a . $b means > ClassA::__concat($a, $b); (Note that both operands are passed in their > original form) > If you want to concat the string representations, you will have to explicitly > convert the objects to strings: > $ret = (string) $a . (string) $b; This first part seems legit to me. > If the concat operator is not overloaded, the behavior is like now, and the > objects are converted implicitly to strings (so $a . $b actually means > (string) $a . (string) $b). > Furthermore an notice is triggered, hinting the user that he could overload > the concat operator. (Maybe here a different message than for the other > operators would be useful). I fear that "hint" notice could break Symfony apps... Couldn't you just not trigger it in this case? -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [VOTE] Userspace operator overloading
On Thursday, March 26, 2020 3:50 AM Jakob Givoni wrote: > On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker wrote: > >> It seems to me that the RFC is not sufficiently specific enough >> regarding the concatenation of instances of classes which implement >> __toString(). > > Exactly what I was thinking too. Would be nice with some examples on this. I am not sure if I can (or should) still add this to the RFC, here some clarification on this: The overloaded concat operator has higher priority than the __toString() method. So if Class A overloades the concat operator, then calling $a . $b means ClassA::__concat($a, $b); (Note that both operands are passed in their original form) If you want to concat the string representations, you will have to explicitly convert the objects to strings: $ret = (string) $a . (string) $b; If the concat operator is not overloaded, the behavior is like now, and the objects are converted implicitly to strings (so $a . $b actually means (string) $a . (string) $b). Furthermore an notice is triggered, hinting the user that he could overload the concat operator. (Maybe here a different message than for the other operators would be useful). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading
On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker wrote: > > It seems to me that the RFC is not sufficiently specific enough > regarding the concatenation of instances of classes which implement > __toString(). Exactly what I was thinking too. Would be nice with some examples on this. > So if we ever wanted to change the value of > PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break. Therefore > the constant's value likely will never change, so using NULL directly to > signal unsupported operand types would be fine, wouldn't it? Agree on this too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
