Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Johannes Schlüter]

On Mon, 2020-03-23 at 18:58 +0100, jan.h.boeh...@gmx.de wrote:
> Hi internals,
> 
> I have opened voting on
> https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> users to overload operators in their own classes.
> 

I consider operator overlaoding in general a good feature (while PHP's
overload for + on arrays is weird)

However I don't like this design.

Consider this case: Some library provides a type A without overloads. I
then create a type B with overload:

class B {
static public __add($lhs, $rhs) {
if ($lhs instanceof A) ... 
elseif($rhs instanceof A) ...
else error
}
} 

as I want my type's addition to commutative I handle this with some if
(probably dispatching. Now I can invoke it:

   new A() + new B(); // calls B::__add()
   new B() + new A(); // calls B::__add() as well

Now the maintainer of A implements the feature request "A should allow
addition with integers", I update my library and suddenly weird things
happen.

   new A() + new B(); // calls A::__add() and explodes, as A doesn't know  B
   new B() + new A(); // calls B::__add() works as before

Now we could establish the best practice that one type's operator calls
the other type's operator in case it can't handle a type. However that
is no good option as it will lead to infinite recursion if neither type
can handle both operands.


The issue is that by forcing type declarations as part of the class, as
members, this forms a closed set, but for many cases a strict closed
set isn't what one wants. For mathematical types having operators
working with integers (and other numeric values) is essential.
Communativity often also is required.  So a true closed set doesn't
work, for an open set can't be created easily in today's PHP. Thus the
RFC tries to tie this together, but this will fall apart and then cause
legacy and BC reasons preventing future improvement.

I believe the pre-requisit is having some form of function overloading,
where operator functions for specific argument types can be defined. In
https://news-web.php.net/php.internals/108425 Andrea created an idea,
which is probably "ugly" but has less usage restrictions. I think
spending time on function overloading (I believe, without proving it,
this can be done with very little cost for non-overlaoded cases - by
adding a flag "overloaded" along visibility flags and check that along
with the visibility check, only in case of an overload to the
"expensive" check, which still is cheaper done in the engine than
if/else chains in userspace) and then take up operator overloading
again, rather than this smart but limited approach. (For whoever does
that: spend time in C++ and its function resolution rules incl. ADL,
not to copy, but to learn) 

johannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Marcio Almada]

>
> Hi internals,
>
> This has been declined in the past, but I just keep making this mistake,
> and believe it deserves reconsideration...
>
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list
>
> Nikita

I have no idea why we failed to approve trailing comma over lists in general,
but this seems to be a step forward. My `git diff` says +1

Thanks,
Márcio

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Christoph M. Becker]

On 27.03.2020 at 14:58, tyson andre wrote:

> I'd just like to add that 
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list seems useful,
> especially now that PSR-12 is approved and 
> https://www.php-fig.org/psr/psr-12/#45-method-and-function-arguments 
> recommends that
> "When the argument list is split across multiple lines, the closing 
> parenthesis and opening brace MUST be placed together on their own line with 
> one space between them."
> (Previously, I don't think there was any attempt at standardizing a 
> recommendation of where the closing parenthesis should go)

The text is identical for PSR-2[1], and even PEAR CS[2] put it that way.

So, yes, I'm +1 here.

[1] 
[2] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[tyson andre]

Hi internals,

I'd just like to add that 
https://wiki.php.net/rfc/trailing_comma_in_parameter_list seems useful,
especially now that PSR-12 is approved and 
https://www.php-fig.org/psr/psr-12/#45-method-and-function-arguments recommends 
that
"When the argument list is split across multiple lines, the closing parenthesis 
and opening brace MUST be placed together on their own line with one space 
between them."
(Previously, I don't think there was any attempt at standardizing a 
recommendation of where the closing parenthesis should go)

```
class ClassName
{
public function aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = []  // comma would be useful here when adding or removing 
in diffs
) {
// method body
}
}
```

- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] switch expression

[Ilija Tovilo]

Hi Gabriel

 

> This doesn't look like it can do fallbacks which are traditional feature of 
> switch statements, can it?

 

You can take a look at the tests to get a feel for what it’s like:

https://github.com/php/php-src/pull/5308/files

 

Multiple conditions are possible:

 

```

return $day switch {

    1, 7 => false,

    2, 3, 4, 5, 6 => true,

};

```

 

Regards

 

Re: [PHP-DEV] [RFC] switch expression

[Gabriel O]

This doesn't look like it can do fallbacks which are traditional feature of
switch statements, can it? What I mean is this
```

case foo:
case bar:
  return 1;
case baz:
  return 2;
```

If we can't do that, I would suggest to go with different name, rather
than reusing "switch".

Re: [PHP-DEV] Re: semicolon terminator for switch cases

[Ilija Tovilo]

Hi Andrea

The reason this doesn't work anymore:

```
If (false);
echo 'Test';
endif;
```

Is because the semicolon is an empty statement:
https://github.com/php/php-src/blob/9e77d5a9da9e80a1bfe226f60ccb12fd8bf9481c/Zend/zend_language_parser.y#L457

This is still valid code:

```
If (false);
echo 'Test';
```

And it always prints. The two semicolons look the same but behave differently 
which is why I'm in favor of deprecating it.

Regards
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php