Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 23:40:22 +0200 Bob Weinand
escribió
> > Am 04.05.2020 um 10:53 schrieb Manuel Canga :
> >
> > Hi internals,
> >
> >
> >
> > I would like to present a possible new RFC( "keep type of reference
> > params" ) for your
> >
> > consideration.
> >
> >
> >
> > Firstly, an example:
> >
> >
> >
> > ```
> >
> > >
> >
> >
> > function my_array_shift( array & $array ) {
> >
> > $array = "string";
> >
> > }
> >
> >
> >
> > $array = [ 0, 1, 2, 3, 4 ];
> >
> >
> >
> > my_array_shift($array);
> >
> >
> >
> > count( $array );
> >
> > ```
> >
> >
> >
> > The result of this code is a warning( in count line ) because of $array is
> > a string.
> >
> > However, I think it should be an error or exception when a string is
> > assigned to $array var.
> >
> > In my opinion, $array var would have to keep its type when function ends.
> >
> >
> >
> > What is your opinion ? Do you see it useful ?
> >
> > Thanks and I'm sorry for my English( I'm a Spanish ).
> >
> > Regards
> >
> > --
> >
> > Manuel Canga
>
> Hey Manuel,
>
> the primary issue (apart from the BC break) here is leaking the reference
> across the function boundary.
>
> function a(array &$a) {
> $GLOBALS["globalA"] = &$a;
> }
>
> funcition b() {
> $GLOBALS["globalA"] = 10;
> }
>
> $a = 1;
> a($a);
> b();
> // $a is magically changed to 10
>
> Yes, you can here verify, that $a is an array at the function boundaries,
> but you cannot afterwards.
>
> If we had proper inout parameters (which do not leak a reference, but assign
> the value of the variable (in callee scope) back to the passed variable from
> caller), then we could easily enforce it.
>
> But as it stands now, this is not an option. (Especially due to the false
> promise this seems to make.)
>
> Bob
Thanks Bob, that was a great example
I explain...I am very forgetful, so it's very easy for me to write somethink
like this:
```
function filter_something( $to_filter) {
$to_filter = strtolower($to_lower);
$to_filter = sanitize_this($to_filter);
.
}
filter_something($my_string);
```
Sometimes, one of these functions can returns a false|null|numeric|... instead
of expected type.
Also, If any function in 'filter_somethid' would throw an exception, value in
$to_filter would finish inconsistent
However, with:
```
function filter_something( inout string $to_filter) {
$to_filter = strtolower($to_lower);
$to_filter = sanitize_this($to_filter);
.
}
filter_something(inout $my_string);
```
PHP could in the end produce exception when any function in `filter_something`
modify type of $my_string or
PHP could keep value of `$to_filter` as well if any function throwed an
exception.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 15:31:52 +0200 Levi Morrison escribió > I think changing reference is a bad idea, even if it's behind some > sort of declare or ini setting or what-have-you. > > I do support `inout`, which has similar high-level outcomes: the > current value is fed in, and when the function returns it has a new > value. I think we should use `&` at the call site, and we should also > permit it optionally for by-ref parameters as it provides a migration > path: first add `&` to all the call sites, then switch it to `inout`. Hi, Levi, Thanks for your opinion. Why don't reverse mode ?. 'inout' is created with the three characteristics: - Check type of out is equal to type of param - Avoid modifying caller variable value when the function throws an exception. ( Like inout of Hacker language ) - Allow explicit call-site pass-by-reference annotation. Then, current references are deprecated and after than, in other version, they are removed. In this way, projects can be adapted gradually Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 15:07:13 +0200 Dan Ackroyd escribió > On Fri, 8 May 2020 at 07:49, Manuel Canga wrote: > > > > What is your opinion ? Do you see it useful ? > > I can see the need; I strongly dislike the idea of using references for this. > > What you're describing is a form of 'out parameters' which have been > mentioned a few times before on this list. > > I've made a note of the general idea here: > https://github.com/Danack/RfcCodex/blob/master/out_parameters.md > > Though the wikipedia article is also good: > https://en.wikipedia.org/wiki/Parameter_(computer_programming)#Output_parameters > > Using references for things like this is a bad idea as references make > it hard to reason about code. In this specific case, having the > function mutate the existing variable is horrible. Hi, Dan, I think nothing is bad practice. It depends of context. Example: global variables, __set/__get, public properties and so on could be considered bad practices, however, they sometimes are useful. References could be a priori bad idea, but if you limit your their dangerousness, they will be less bad. > > > If nobody objects to this RFC > > While you categorically must do what you must, I don't think you will > get much benefit from raising this as an RFC until you find someone > who can and is willing to implement it. I agree :'( > > Actually, just finding any core contributor who is willing to say that > they would back this idea might be a good idea. > > And yes, phpinternals could still really do with an 'informal but only > to open to voters' feedback mechanism. Someone should do something > about thatwait I'm _someone_. And I have wiki permissions. > > So here's a page for a non-binding 'indication of interest' poll: > https://wiki.php.net/indication_of_interest/keep_type_of_reference_params Thanks so much, Dan > > If anyone disagrees with the text, either please suggest a change or > edit it if you have karma. I'd add( but I don't have karma ): Add a new`inout` keyword( very similar to 'inout' of Hack ) in order to: - Check type of out is equal to type of param( like example of my first email ). - Avoid modifying caller variable value when the function throws an exception. ( Thanks to Mathew for link to inout* of Hacker language ) - Allow explicit call-site pass-by-reference annotation. ( Thanks to Rowands for link** to Nikita's RFC ) * https://docs.hhvm.com/hack/functions/inout-parameters ** https://wiki.php.net/rfc/explicit_send_by_ref > cheers > Dan > Ack Thanks again, Dan, Regards -- Manuel Canga -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 13:03:59 +0200 Thomas Gutbier
escribió
> Isn't that already solved for typed properties?
>
> Consider this:
>
> class A { public static int $number = 5; }
> $num = ::$number;
> $num = "String";
>
> This will result in an uncaught TypeError,
> see https://3v4l.org/XC6hk
>
> I would think, it would be consistent if referenced parameters
> behaved in exactly the same way.
>
> Regards,
> Thomas
>
>
Hi, Tomas,
That option was my first thought. However, people( and me ) I know, normally
use local vars for function calls.
Thanks Thomas for your opinion.
Regards
--
Manuel Canga
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keep type of reference params
En vie, 08 may 2020 12:37:29 +0200 G. P. B. escribió I think everyone can agree this is useful. But the issue here is the implementation. Because from what I know PHP's references are a special kind of pain in the engine. That's why the common wisdom is to use references in PHP as least as possible. And IIRC what you are trying to achieve would need a major overhaul of how references work and someone who wanted to tackle this would have done it on their own and propose an RFC at the same time. So sadly unless something semi-concrete shows up, I'm considering this a pipe dream. But I'd gladly be shown otherwise. Hi, George. Thanks for your opinion. Nikita porposed a RFC in order to improve refences( https://wiki.php.net/rfc/explicit_send_by_ref, links thanks to Rowan ). Maybe, he wants to code this. Regards -- Manuel Canga,
[PHP-DEV] [DECLINED] match expression RFC
Hi internals I closed the vote on the match expression RFC. https://wiki.php.net/rfc/match_expression First of all, thank you to everybody who participated! It was declined with 28 no and 6 yes votes. There were three main criticisms: 1. The RFC wasn't discussed extensively enough and too many changes were made last minute 2. match should be expression only (no blocks) 3. Omitting (true) should loosely compare the arm condition to true Criticism 1 is absolutely justified and 3 makes sense to me. Unfortunately, I think criticism 2 somewhat defeats the purpose of the RFC (at least how I envisioned it). The main motivation to me was a new switch statement with safer semantics. Returning values was a nice secondary feature. According to Nikitas analysis (1) an expression only match would be usable in roughly 40% of cases where a switch would've previously been used. Failing to address the other 60% seems less than ideal, especially given the fact that the plan is to extend match with pattern matching. If we do decide to remove blocks I think the RFC needs to find a different motivation since criticizing switch without offering an alternative seems disingenuous. I will take the next few days to think about how to move forward. Thanks again! Ilija 1) https://externals.io/message/109842#109868 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
