Hi Mike,
First, I'd just like to reiterate that I absolutely see benefits in this
proposal, and am definitely not campaigning for it to be abandoned as a
bad idea. Like with any proposal, we have to weigh those benefits
against the costs, and my current personal opinion is that the scales
come down *very slightly* on the cost side.
I will also just say that you have made some valid points about
different ways people might perceive this change, and my fears on that
score may be overblown.
On 23/02/2020 07:03, Mike Schinkel wrote:
The RFC does not require mandatory use, period.
The "cost" you worry about will not exist unless and until a future RFC
proposes to make it mandatory and that RFC is accepted.
The RFC states very clearly that the full benefit of the change will
only be realised by making the markers mandatory in some way, and
includes specific discussion of how that might be introduced. Put
simply, tools (and even humans) get most from knowing that a particular
line of code *won't* pass anything by reference, and optional markers
can't guarantee that.
I am analysing the proposal on that basis, just as I would analyse a
proposed deprecation on the basis that the deprecated feature will one
day be removed.
If we analyse it on the basis of it *never* becoming mandatory, we have
to adjust our analysis of both costs *and* benefits.
Regarding prefer-ref and prefer-val:
function call_with_current_user(Callable $callable, int &$foo, int $bar ) {
return call_user_func( $callable, current_user(), &$foo, $bar );
}
If you define the function this way, all callers are *required* to pass
the parameter by reference. That immediately means that this is a fatal
error:
call_with_current_user('foobar', 42, 42);
Internal functions have the magical ability to accept both literals
values and reference variables, whereas userland functions have to
choose one or the other.
As an example of the second, even under strict settings, calls to certain internal
functions will have an optional & at the call site, which changes their
behaviour.
To those without knowledge of the core, those functions simply have to be remembered as
"magic", because their behaviour can't be modelled as part of the normal
language.
I am unclear how the optional ampersand at the call site will change the
behavior.
I was referring to this line in the RFC:
If the argument is a prefer-ref argument of an internal function, then
adding the |&| annotation will pass it by reference, while not adding
it will pass it by value. Outside this mode, the passing behavior
would instead be determined by the VM kind of the argument operand.
That means that for any function implemented internally as "prefer-ref",
the user can now *choose* whether their variable will be overwritten by
the function. I don't know exactly which functions this would affect,
because as far as I know, the manual doesn't have a standard way to
annotate "prefer-ref". Which is kind of my point: it's magic behaviour
which sits outside most people's understanding of the language.
I don't particularly see a problem with requiring a third change in
the future. Hindsight is a wonderful clarifier. And I believe
elsewhere you have been debating me over the need for incremental
change. Caveat emptor.
The distinction I would make is between incremental change, and
contradictory change. If we later introduce out parameters in a way
that's compatible with call-site &, that would indeed be incremental
change; the effort spent adding & would move code closer to the final
state. If we end up introducing call-site "out", the effort spent adding
& will simply be compounded with the effort spent adding "out".
Predicting the future is a mug's game, but it's at least worth exploring
some possible futures, and how decisions now might help or hinder them.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
