scalar type-casting

If the caller sees only the signature, then the function can do
literally anything to their passed by reference variable. The caller is
giving full control and "ownership" of that variable, and shouldn't make
any assumptions about what it will look like when it comes back.

Understood, only this isn't the function doing something - it's the
language.

But I guess the best thing under any circumstances is to simply avoid using
references entirely - you won't have these problems then.

The main point was, I'd still very much like to see Anthony's RFC revived
:-)

So I guess this should be updated:

"when an internal function accepts a typed parameter by reference, if the
magic cast method is defined on the passed in object, an error is raised as
the cast cannot be performed because of the reference."

Perhaps to:

"when a function receives a type-hinted parameter by reference, if the
magic cast method is defined on the passed in object, the variable in the
calling scope is immediately overwritten with the result of the type-cast."

I don't happen to like it, but that's consistent with the existing
behavior, right?

On Sun, Apr 9, 2017 at 1:07 PM, Rowan Collins rowan.collins@gmail.com
wrote:

Example:

class Foo { public function __toString() { return "foo"; } }
function append_to(string &$str) { $str .= "_bar"; }
$foo = new Foo();
append_to($foo);
var_dump($foo); // string(7) "foo_bar"

In this example, the caller's instance of Foo gets wiped out and
replaced
by a string

While this looks surprising in the form you've written it, it should only
really be a surprise to the function author, not the caller. If the caller
sees only the signature, then the function can do literally anything to
their passed by reference variable. The caller is giving full control and
"ownership" of that variable, and shouldn't make any assumptions about what
it will look like when it comes back.

For example, you don't even need PHP7 to do this:

class Foo { public function __toString() { return "foo"; } }
function append_to(&$str) { $str = (string)$str . "_bar"; }
$foo = new Foo();
append_to($foo);
var_dump($foo); // string(7) "foo_bar"

I don't think it's any more unreasonable for a reference parameter to
change type in the parameter handling of your example function (with
strict_types off) than inside the body of my example function. Of course,
by setting strict_types=1, the caller can change the implicit cast to an
implicit assertion, and get an error in your example; it won't save them
from my example, though.

Regards,

--
Rowan Collins
[IMSoP]

My concern is actually neither performance nor brevity - my concern is, can
you read the code and actually understand what it does, can you write code
without running into surprising side-effects, and so on.

DbC might have merit in terms of performance, but perhaps not so much in a
scripting language - if performance was critical to a given project, I
would not be using a scripting language. The addition of DbC and marginally
better performance for certain specific use-cases wouldn't change that for
me.

Hi Rasmus,

Although DbC is not what you need, but DbC could solve your issue
more efficiently. i.e. Faster execution, not shorter code.

https://wiki.php.net/rfc/dbc2

With DbC, caller has responsibility to pass correct parameters.

$one = "1";
$one_int = (int) $one;
add_one($one_int);

add_one(&$value)
require (is_int($value))
{
$value += 1;
}

// Caller has responsibility to pass correct parameters.
$one = filter_validate($_GET['var'], FILTER_VALIDATE_INT);
add_one($one);

class Foo { public function __toString() { return "foo"; } }
function append_to(string &$str) { $str .= "_bar"; }
$foo = new Foo();
append_to($foo);
var_dump($foo); // string(7) "foo_bar"

class Foo { public function __toString() { return "foo"; } }

function append_to(&$str)
require (is_string($str))
{
$str .= "_bar";
}

$foo = new Foo();

// Caller has responsibility to pass correct parameters, but it's not
append_to($foo); // Error at DbC precondition check in append_foo()
var_dump($foo); // Cannot reach here in dev mode

I really like parameter type check.
Problem is type check makes execution slower.
Another problem is type check is not enough for many codes.

With DbC support, we can specify any expressions. Therefore, we can
check much more complex requirements for functions/methods at
development time.

e.g.
function save_age($user_age)
require (is_int($user_age))
require ($user_age >= 0)
require ($user_age < 150)
{
save_to_somewehre($user_age);
}
//Note: All input parameters must be validated to be correct value for the
app. e.g. use filter_validate()/etc

What you really need might be DbC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net