Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

[Pedro Magalhães]

On Tue, May 26, 2020 at 3:46 PM Marco Pivetta  wrote:

> Considering that, as far as I know, only the constructor remains "special".
>

Leaving the special case only for constructors instead of all magic methods
sounds better to me. Right now, that sounds like a winning compromise for
the RFC. It is still an exception to a rule, but one that can be better
justified.

Thanks,
Pedro

Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode

[Katie Volz]

 On Sun, May 24, 2020 at 7:29 PM Rowan Tommins 
wrote:

> In my mind error_reporting should make absolutely no difference. As you
> say, this option would be for people who don't want to interact with the
> current error system in any way, and that includes its global
> configuration state.
>

My main concern for this was that it would make implementation more
difficult - however it turned out to be fairly straightforward.

One note on this - currently declare() statements do not allow constants or
expressions in them.  I had to patch zend_compile.c to allow this, so this
will affect other declare statements as well (for example,
declare(ticks=E_ALL - 37) will be valid).  Unknown constants or incorrect
types (ex: declare(error_exception=[]), declare(error_exception=E_ALL -
FOO_BAR)) will fail here.

RE: [PHP-DEV] Draft RFC callable types + callable type/function autoloading

[Iván Arias]

> Hi internals,
>
> A while ago, I spent some time thinking about callables, and how they
> are not very consistent, which makes people sad:
> https://wiki.php.net/rfc/consistent_callables
>
> The reason I didn't pursue that RFC is that although tidying up PHP
> core to be more consistent would be nice, it would be a large amount
> of work, that wouldn't dramatically improve the developer experience
> when programming in PHP. In fact it would mostly just break otherwise
> working code.
>
> What would be better would be an RFC to make callables be more useful,
> specifically by allowing you to define the parameter and return types
> for them. Making it possible to autoload those types would be
> required, and function autoloading is also a feature that has been
> desired for a while.
>
> So here are two draft RFCs:
>
> Callable types
> https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.md
>
> Function + callable type autoloading
> https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md
>
> I'll leave them on github for the moment, as it is easier to do PRs
> and track issues there but I wanted to gather initial feedback before
> getting closer to the RFC cutoff date.
>
> I'll move them to the wiki and formally submit them for discussion
> when the implementation is closer to being done.

Hi!

Just a Little question. I see this other document in the same repo:
https://github.com/Danack/FunctionTypes/blob/master/3_referencing_functions_and_callables.md

Are you planning to also raise it?
As userland developer it really bothers me to type function and method names in 
strings.

Thanks in advance!

Un saludo,
Iván Arias.

De: Dan Ackroyd
Enviado: miércoles, 20 de mayo de 2020 15:01
Para: PHP internals
Asunto: [PHP-DEV] Draft RFC callable types + callable type/function autoloading

Hi internals,

A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callables

The reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.

What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.

So here are two draft RFCs:

Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.md

Function + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md

I'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.

I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

[Marco Pivetta]

Hey Pedro,

On Tue, May 26, 2020, 16:34 Pedro Magalhães  wrote:

> Hi Marco,
>
> Thanks for the feedback.
>
> About the sealed type example, it is true that `final protected` wouldn't
> achieve the same thing. But as an attempt to provide an alternative design,
> wouldn't an union type of the desired children be a better choice?
>

Difficult without having type aliases for union types: possible with tools
like psalm, but fragile and easy to work around for less experienced devs.
The construct in my example is instead very hard to avoid unless you know
about `ReflectionClass#newInstanceWithoutConstructor()`

it is supported by a broken behavior
>

Not really: the `__`-prefixed methods are indirectly part of the object's
API, and I seal them off by design, guiding consumers of my implementation
& type.

About lifting the restriction only to magic methods, I don't really like
> that approach. Anything that makes them more special feels like a step in
> the wrong direction. If we were to lift that restriction, I would say that
> it should be lifted for any method, leaving the RFC to deal only with the
> static and abstract cases.
>

Magic methods are indeed a pain in the language: I'm trying to make the
best use for them (there's already enough bad usage out there).


About the serialization example, I think that goal is equally possible to
> achieve with final protected.
>

Good point!

Considering that, as far as I know, only the constructor remains "special".

>

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

[Pedro Magalhães]

Hi Marco,

Thanks for the feedback.

About the sealed type example, it is true that `final protected` wouldn't
achieve the same thing. But as an attempt to provide an alternative design,
wouldn't an union type of the desired children be a better choice?
I can see some usefulness in it but IMHO, it is supported by a broken
behavior, it doesn't make sense to talk about private symbol overrides.
That shouldn't be a thing.
With that said, I don't think the RFC has to be all or nothing, but we
would leave an exception behind.

About lifting the restriction only to magic methods, I don't really like
that approach. Anything that makes them more special feels like a step in
the wrong direction. If we were to lift that restriction, I would say that
it should be lifted for any method, leaving the RFC to deal only with the
static and abstract cases.

About the serialization example, I think that goal is equally possible to
achieve with final protected.

Regards,
Pedro

On Fri, May 22, 2020 at 5:25 PM Marco Pivetta  wrote:

> Hey Pedro,
>
> On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães  wrote:
>
>> Hi internals,
>>
>> I want to put up for discussion an RFC (
>> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
>> remove some inappropriate signature checks that are still done on private
>> methods. Namely, those checks are:
>>
>> - When a method has the same name as a parent's final private method
>> - When a method has the same name as a parent's static private method and
>> the child's method is non-static, or vice-versa
>> - When a method has the same name as a parent's concrete private method
>> and
>> the child's method is abstract
>>
>> I have 2 open issues on the RFC that I would like to hear some opinions
>> on.
>> - Whether or not to issue a compiler warning whenever "final private
>> function" is used, to alert the user that it will not achieve what that
>> construct is currently used for. The disadvantage of introducing it is the
>> BC break.
>> - Whether or not to make an exception to this rule for magic methods.
>> Given
>> that this is widely to restrict object instantiation and cloning, it could
>> make sense to still allow the use on those cases. However, I think that
>> the
>> similar effect that can be achieved with "final protected function" would
>> cover most of the cases. And if we open up that exception for magic
>> methods, for the sake of clarity maybe we should just keep the "final
>> private" behavior on all methods and just change the static and the
>> abstract behaviors. Some discussion on this subject can be found on the
>> PR (
>> https://github.com/php/php-src/pull/5401) for this RFC.
>>
>
> Overall, this RFC breaks some design capabilities that are within the
> language, specifically around `__`-prefixed methods in the language.
>
> For instance, I design (on purpose) sealed types as following:
>
> ```php
> abstract class Email
> {
> final private function __construct() {}
> public static function business(): Business {
> return new Business();
> }
> public static function personal(): Personal {
> return new Personal();
> }
> }
>
> final class Business extends Email {}
> final class Personal extends Email {}
> ```
>
> The above approach guarantees that no further subtypes exist for `Email`,
> other than `Business` or `Personal`, effectively forming a safe union type,
> which can only be broken by reflection.
>
> In addition to that, I often prevent serialization of types that are not
> intended to be serialized (when not final):
>
> ```php
> abstract class InMemorySecret
> {
> final private function __sleep() {}
> }
> ```
>
> Effectively, the `final` modifier applies to `private` symbols too, and
> prevents child classes from deviating from imposed design constraints.
>
> It is **intentional** for `private` symbol overrides to not compile in
> these cases.
>
> Both of the above examples only apply to special/magic methods: I can see
> and understand that for custom methods this RFC may be valid, and adding a
> further refinement to lift the restriction only on custom methods is a good
> idea.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

[PHP-DEV] Re: [VOTE] Unbundle ext/xmlrpc

[Christoph M. Becker]

On 12.05.2020 at 12:05, Christoph M. Becker wrote:

> I have opened the voting for
>
> 
>
> The voting period ends on 2020-05-26 (12:00 UTC).

I'm pleased to announce that the RFC has been accepted unanimously
(50:0).  I'll do the unbundling as soon as possible.

Thanks,
Christoph

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed

[Gabriel Caruso]

On Fri, 1 May 2020 at 13:06, Gabriel Caruso 
wrote:

> On Fri, 1 May 2020 at 01:47, Dan Ackroyd  wrote:
>
>> On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso 
>> wrote:
>> >
>> > If there are no further requests or comments, I'll open this RFC for
>> voting
>> > next Friday.
>>
>> Hi Gabriel,
>>
>> I think it would be better to hold off until the mixed RFC has been voted
>> on.
>>
>> If that passes, the four signatures that still have mixed in the
>> docblock, could be updated to use mixed in the actual signature.
>>
>> There's plenty of time until the release process starts.
>>
>> cheers
>> Dan
>> Ack
>>
>
> Hello sir.
>
> I'll hold to start the voting process for this one until
> https://wiki.php.net/rfc/mixed_type_v2 gets discussed and voted, no
> problems.
>
> Thanks for the head up.
>
> Best regards,
>

Alright, `mixed` type RFC voted and merged, time to move with this one.

We still got time, so I'll wait until this Friday (29/05) to start the
voting, if someone still has any objections or questions regarding this RFC.

-- Gabriel Caruso

[PHP-DEV] Improvement to errors

[David Rodrigues]

Hello!

I've been thinking that some errors in PHP are very difficult to
understand. Especially when we use two equal functions with different
arguments on the same line. The error does not make it clear where the
error is.

$strVariable = 'hello';
$nullVariable = null;
return strlen($strVariable) - strlen($nullVariable);

The second strlen() will causes an error: "strlen() expects parameter 1 to
be string, null given - line 107".

So I thought of two possible solutions:

1. Improve the error description, displaying parameters and information
that are easy to reuse (eg. variables).

- "strlen($nullVariable) expects parameter 1 to be string, null given -
line 107"

2. Indicate the offset from where the function was called, along with the
line (which already exists).

- "strlen() expects parameter 1 to be string, null given - line 107:30"

I believe that the second solution is the simplest to be implemented and
already solves the problem enough.


Atenciosamente,
David Rodrigues