> On Feb 20, 2020, at 9:13 AM, Nikita Popov <nikita....@gmail.com> wrote: > > I'd like to start the discussion on the "explicit call-site > pass-by-reference" RFC again: > https://wiki.php.net/rfc/explicit_send_by_ref
> On Feb 20, 2020, at 6:04 PM, Larry Garfield <la...@garfieldtech.com> wrote: > > If $this->data is itself an object, then you have a concern for data > manipulation (spooky action at a distance) even if it's passed by value. > Given how much data these days is objects, and thus the problem exists > regardless of whether it's by value or by reference passing, adding steps to > make pass-by-reference harder doesn't seem to help much. > > --Larry Garfield > On Feb 20, 2020, at 6:26 PM, Christian Schneider <cschn...@cschneid.com> > wrote: > > +1 > > The whole discussion about being worried about 'malicious' libraries altering > your precious scalar values misses the fact that PHP is not a pure language, > there are many ways a function can have side-effects, Larry pointing out one > obvious one. > Speaking of language editions: Trying to solve one obscure case (and one > which is easily enough detectable by statical analysis) by introducing such a > big BC break could render a whole edition ineligible for a software project. > So beware, features bundled in one (hypothetical) edition better not break > too many different things at the same time. > > If you don't trust your library code then you're in deep trouble anyway. A huge +1 to Nikita's RFC. A noted -1 to both Larry and Christian's objection. Why? Because perfect should not be the enemy of the significant improvement for specific use-cases unless it can be illustrated that making the improvement disallows future perfection. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
