[RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed

5 years ago by Claude Pache — view source — reply

unread

Le 5 avr. 2020 à 16:01, Gabriel Caruso carusogabriel34@gmail.com a écrit :

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hi,

Regarding __construct(), etc. Since those methods are not supposed to return anything, they ought to accept the void return pseudo-type in their signature, which means exactly that: “do not return anything”. I consider that the current behaviour (i.e., not accepting the : void signature) as a bug, and was very surprised when I stumbled on it.

Also, I raise the following question:

Should omitted types be added implicitly? I.e., if I write: function __toString() { } should the compiler interpret it as function __toString(): string { } ? (Currently, it is not the case.)

Doing so would raise BC concerns for some, uh, creative uses of magic methods. On the other hand, that may help to add progressively type informations on magic methods, since there is no need to synchronise manually classes and subclasses (the compiler would do it automatically for you). Concrete example here: https://3v4l.org/hTMvA https://3v4l.org/hTMvA

—Claude

5 years ago by Gabriel Caruso — view source — reply

unread

Le 5 avr. 2020 à 16:01, Gabriel Caruso carusogabriel34@gmail.com a
écrit :

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hi,

Hello Claude,

Regarding __construct(), etc. Since those methods are not supposed to
return anything, they ought to accept the void return pseudo-type in
their signature, which means exactly that: “do not return anything”. I
consider that the current behaviour (i.e., not accepting the : void
signature) as a bug, and was very surprised when I stumbled on it.

I'll add to the RFC adding the possibility of typing the __construct() as
: void as one of the changes.

Also, I raise the following question:

Should omitted types be added implicitly? I.e., if I write: function __toString() { } should the compiler interpret it as function __toString(): string { } ? (Currently, it is not the case.)

Doing so would raise BC concerns for some, uh, creative uses of magic
methods. On the other hand, that may help to add progressively type
informations on magic methods, since there is no need to synchronise
manually classes and subclasses (the compiler would do it automatically for
you). Concrete example here: https://3v4l.org/hTMvA

This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.

—Claude

Thanks!

5 years ago by Gabriel Caruso — view source — reply

unread

On Sat, 11 Apr 2020 at 22:40, Gabriel Caruso carusogabriel34@gmail.com
wrote:

Le 5 avr. 2020 à 16:01, Gabriel Caruso carusogabriel34@gmail.com a
écrit :

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hi,

Hello Claude,

Regarding __construct(), etc. Since those methods are not supposed to
return anything, they ought to accept the void return pseudo-type in
their signature, which means exactly that: “do not return anything”. I
consider that the current behaviour (i.e., not accepting the : void
signature) as a bug, and was very surprised when I stumbled on it.

I'll add to the RFC adding the possibility of typing the __construct()
as : void as one of the changes.

Also, I raise the following question:

Should omitted types be added implicitly? I.e., if I write: function __toString() { } should the compiler interpret it as function __toString(): string { } ? (Currently, it is not the case.)

Doing so would raise BC concerns for some, uh, creative uses of magic
methods. On the other hand, that may help to add progressively type
informations on magic methods, since there is no need to synchronise
manually classes and subclasses (the compiler would do it automatically for
you). Concrete example here: https://3v4l.org/hTMvA

This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.

—Claude

Thanks!

Btw, the problem that you reported about incompatible signatures will be
fixed on PHP 8: https://3v4l.org/hTMvA/rfc#git-php-master.

I've also added a test on the implementation ensuring the following:
https://3v4l.org/5010J/rfc#git-php-master.

Thanks!

-- Gabriel Caruso

5 years ago by Gabriel Caruso — view source — reply

unread

On Sat, 11 Apr 2020 at 23:29, Gabriel Caruso carusogabriel34@gmail.com
wrote:

On Sat, 11 Apr 2020 at 22:40, Gabriel Caruso carusogabriel34@gmail.com
wrote:

Le 5 avr. 2020 à 16:01, Gabriel Caruso carusogabriel34@gmail.com a
écrit :

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hi,

Hello Claude,

Regarding __construct(), etc. Since those methods are not supposed to
return anything, they ought to accept the void return pseudo-type in
their signature, which means exactly that: “do not return anything”. I
consider that the current behaviour (i.e., not accepting the : void
signature) as a bug, and was very surprised when I stumbled on it.

I'll add to the RFC adding the possibility of typing the __construct()
as : void as one of the changes.

Also, I raise the following question:

Should omitted types be added implicitly? I.e., if I write: function __toString() { } should the compiler interpret it as function __toString(): string { } ? (Currently, it is not the case.)

Doing so would raise BC concerns for some, uh, creative uses of magic
methods. On the other hand, that may help to add progressively type
informations on magic methods, since there is no need to synchronise
manually classes and subclasses (the compiler would do it automatically for
you). Concrete example here: https://3v4l.org/hTMvA

This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.

—Claude

Thanks!

Btw, the problem that you reported about incompatible signatures will be
fixed on PHP 8: https://3v4l.org/hTMvA/rfc#git-php-master.

I've also added a test on the implementation ensuring the following:
https://3v4l.org/5010J/rfc#git-php-master.

Thanks!

-- Gabriel Caruso

RFC and implementation have been updated.

I'll open it for voting this Friday (17-04-2020) if there's anything else
to discuss.

Best regards,

5 years ago by Nicolas Grekas — view source — reply

unread

Hello Gabriel,

https://wiki.php.net/rfc/magic-methods-signature

RFC and implementation have been updated.

There are a few things I don't understand from the RFC, let me list from
the examples.

This RFC proposes to introduce the following signatures checks when magic
methods are typed:

My general question is: what does this mean exactly?

/** @return mixed */
Foo::__call(string $name, array $arguments);

/** @return mixed */
Foo::__callStatic(string $name, array $arguments);

/** @return mixed */
Foo::__get(string $name);

Does this mean we won't be allowed to declare __call($name, $arguments);?

This looks against LSP to me.

Foo::__clone(): void;

/** @param mixed $args */
Foo::__construct($args): void;

Foo::__destruct(): void;

Is void going to be mandatory now? This should be specified in the RFC I
think.

If it's about to allow void where it wasn't allowed, I'm personally not
convinced it's a good idea to open one more code-style war on this topic.
When there is only one way to declare something, there is no need to come
to any agreement about the code style. That's a win.

Foo::__isset(string $name): bool;
Foo::__unset(string $name): void;

Same comment about LSP, but also about the type: isn't it allowed to have
integers as keys? How does this play with strict_type and array access?

/** @param mixed $value */
Foo::__set(string $name, $value): void;

Is the return now going to be mandatory?

And the BIG question: is all this worth the BC break?

Thanks,

Nicolas

5 years ago by Gabriel Caruso — view source — reply

unread

On Tue, 14 Apr 2020 at 15:24, Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:

Hello Gabriel,

https://wiki.php.net/rfc/magic-methods-signature

RFC and implementation have been updated.

There are a few things I don't understand from the RFC, let me list from
the examples.

This RFC proposes to introduce the following signatures checks when
magic methods are typed:

My general question is: what does this mean exactly?

/** @return mixed */
Foo::__call(string $name, array $arguments);

/** @return mixed */
Foo::__callStatic(string $name, array $arguments);

/** @return mixed */
Foo::__get(string $name);

Does this mean we won't be allowed to declare __call($name, $arguments);?

This looks against LSP to me.

Foo::__clone(): void;

/** @param mixed $args */
Foo::__construct($args): void;

Foo::__destruct(): void;

Is void going to be mandatory now? This should be specified in the RFC I
think.

If it's about to allow void where it wasn't allowed, I'm personally not
convinced it's a good idea to open one more code-style war on this topic.
When there is only one way to declare something, there is no need to come
to any agreement about the code style. That's a win.

Hello Nicolas

No, nothing is gonna be mandatory.

As per the RFC:

This RFC proposes to introduce the following signatures checks when magic
methods are typed:

These checks are only gonna be performed when you type your signatures and
only when you type. So, your example: __call($name, $arguments) will
work just fine, same as if you don't type __clone with : void.

Is there a better way to phrase that in the RFC?

Foo::__isset(string $name): bool;
Foo::__unset(string $name): void;

Same comment about LSP, but also about the type: isn't it allowed to have
integers as keys? How does this play with strict_type and array access?

Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But, if
you call as a method, yes: https://3v4l.org/0VmYQ.

So this should be documented in the RFC as a BC Break.

/** @param mixed $value */
Foo::__set(string $name, $value): void;

Is the return now going to be mandatory?

No, as explained above.

And the BIG question: is all this worth the BC break?

My main motivation is to make sure that developers are using the magic
methods with the correct type, nothing else. If everyone then agrees that
not having these checks is better for the language, no problem on closing
this RFC :)

Let me know your thoughts.

Thanks,

Thanks,

Nicolas

5 years ago by Guilliam Xavier — view source — reply

unread

Hi, just chiming in on a specific question/answer:

On Tue, Apr 14, 2020 at 3:46 PM Gabriel Caruso
carusogabriel34@gmail.com wrote:

On Tue, 14 Apr 2020 at 15:24, Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:

Foo::__isset(string $name): bool;
Foo::__unset(string $name): void;

Same comment about LSP, but also about the type: isn't it allowed to have
integers as keys? How does this play with strict_type and array access?

Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But, if
you call as a method, yes: https://3v4l.org/0VmYQ.

Actually there are ways to use integers as property names, but they
are converted to strings on creation: https://3v4l.org/0k4LS and
https://3v4l.org/HhPZP (also https://3v4l.org/Ts42B).
ArrayAccess doesn't use magic __isset(string $name) but interface
offsetExists(mixed $offset).

Regards,

--
Guilliam Xavier

5 years ago by Nicolas Grekas — view source — reply

unread

No, nothing is gonna be mandatory.

As per the RFC:

This RFC proposes to introduce the following signatures checks when
magic methods are typed:

These checks are only gonna be performed when you type your signatures and
only when you type. So, your example: __call($name, $arguments) will
work just fine, same as if you don't type __clone with : void.

Is there a better way to phrase that in the RFC?

OH, good news then. This should be formulated with more sentences I think,
e.g:

When any of the listed magic method use type hints, this RFC will enforce
that only the supported types are used.
When they don't declare a type, nothing specific will happen.

Also, add this somewhere maybe:

This limits the BC break to methods that declare a wrong type.

Because this is what this is about, right?

Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But,
if you call as a method, yes: https://3v4l.org/0VmYQ.

So this should be documented in the RFC as a BC Break.

Yes, the BC break is bigger when the magic methods are used directly,
that's true and should be mentioned to.

And the BIG question: is all this worth the BC break?

My main motivation is to make sure that developers are using the magic
methods with the correct type, nothing else. If everyone then agrees that
not having these checks is better for the language, no problem on closing
this RFC :)

Now that I understand that the scope of the BC break is quite narrow, I
think you answered the question on my side.

I'm just not sold on allowing "void" on __construct, because the very
concept of a return type on a constructor is ... void, and also because of
the code style choices this will open (and the CS "wars" I mentioned).

Thanks,
Nicolas

5 years ago by Claude Pache — view source — reply

unread

Le 14 avr. 2020 à 16:54, Nicolas Grekas nicolas.grekas+php@gmail.com a écrit :

I'm just not sold on allowing "void" on __construct, because the very concept of a return type on a constructor is ... void, and also because of the code style choices this will open (and the CS "wars" I mentioned).

This issue is not specific to magic method like __construct(). It is the whole concept of “void” as return type which is, say, “problematic”.

In fact, “void” is not really a return type. It is a way to state that the method is not supposed to return anything, which means, as you said very well, that “the very concept of return type on [this method] is void”.

That might be a reason to reject the concept of “void” as return type. Or to revive https://wiki.php.net/rfc/allow-void-variance https://wiki.php.net/rfc/allow-void-variance . But again, the issue is orthogonal to the fact that this particular method is magic, and we should not cherry-pick and reject the concept of “void” for __construct() and similar magic methods only.

—Claude

5 years ago by Nikita Popov — view source — reply

unread

Le 14 avr. 2020 à 16:54, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :

I'm just not sold on allowing "void" on __construct, because the very
concept of a return type on a constructor is ... void, and also because of
the code style choices this will open (and the CS "wars" I mentioned).

This issue is not specific to magic method like __construct(). It is the
whole concept of “void” as return type which is, say, “problematic”.

In fact, “void” is not really a return type. It is a way to state that the
method is not supposed to return anything, which means, as you said very
well, that “the very concept of return type on [this method] is void”.

That might be a reason to reject the concept of “void” as return type. Or
to revive https://wiki.php.net/rfc/allow-void-variance <
https://wiki.php.net/rfc/allow-void-variance>; . But again, the issue is
orthogonal to the fact that this particular method is magic, and we should
not cherry-pick and reject the concept of “void” for __construct() and
similar magic methods only.

Constructors not having a return type is standard behavior across most
(all?) languages. You can't specify a constructor return type in C++. You
can't specify one in C#. You can't specify one in Java. Off-hand, I can't
name a language that both has a first-class constructor concept (Rust's
"new" idiom does not count) and specifies a return type on it.

It would naturally follow that, yes, you can't specify a constructor return
type in PHP either, just like we enforce right now. Unless we have some
strong reason to deviate from standard behavior that I do not see?

Regards,
Nikita

5 years ago by Claude Pache — view source — reply

unread

Le 14 avr. 2020 à 18:53, Nikita Popov nikita.ppv@gmail.com a écrit :

Le 14 avr. 2020 à 16:54, Nicolas Grekas <nicolas.grekas+php@gmail.com mailto:nicolas.grekas%2Bphp@gmail.com> a écrit :

I'm just not sold on allowing "void" on __construct, because the very concept of a return type on a constructor is ... void, and also because of the code style choices this will open (and the CS "wars" I mentioned).

This issue is not specific to magic method like __construct(). It is the whole concept of “void” as return type which is, say, “problematic”.

In fact, “void” is not really a return type. It is a way to state that the method is not supposed to return anything, which means, as you said very well, that “the very concept of return type on [this method] is void”.

That might be a reason to reject the concept of “void” as return type. Or to revive https://wiki.php.net/rfc/allow-void-variance https://wiki.php.net/rfc/allow-void-variance <https://wiki.php.net/rfc/allow-void-variance https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is orthogonal to the fact that this particular method is magic, and we should not cherry-pick and reject the concept of “void” for __construct() and similar magic methods only.

Constructors not having a return type is standard behavior across most (all?) languages. You can't specify a constructor return type in C++. You can't specify one in C#. You can't specify one in Java. Off-hand, I can't name a language that both has a first-class constructor concept (Rust's "new" idiom does not count) and specifies a return type on it.

It would naturally follow that, yes, you can't specify a constructor return type in PHP either, just like we enforce right now. Unless we have some strong reason to deviate from standard behavior that I do not see?

Regards,
Nikita

Do those languages allow to return something from the constructor (as does PHP currently)? because I’m more interested in the semantics of : void than the exact way to have it.

—Claude

5 years ago by Nikita Popov — view source — reply

unread

Le 14 avr. 2020 à 18:53, Nikita Popov nikita.ppv@gmail.com a écrit :

On Tue, Apr 14, 2020 at 6:07 PM Claude Pache claude.pache@gmail.com
wrote:

Le 14 avr. 2020 à 16:54, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :

I'm just not sold on allowing "void" on __construct, because the very
concept of a return type on a constructor is ... void, and also because of
the code style choices this will open (and the CS "wars" I mentioned).

This issue is not specific to magic method like __construct(). It is the
whole concept of “void” as return type which is, say, “problematic”.

In fact, “void” is not really a return type. It is a way to state that
the method is not supposed to return anything, which means, as you said
very well, that “the very concept of return type on [this method] is void”.

That might be a reason to reject the concept of “void” as return type. Or
to revive https://wiki.php.net/rfc/allow-void-variance <
https://wiki.php.net/rfc/allow-void-variance>; . But again, the issue is
orthogonal to the fact that this particular method is magic, and we should
not cherry-pick and reject the concept of “void” for __construct() and
similar magic methods only.

Constructors not having a return type is standard behavior across most
(all?) languages. You can't specify a constructor return type in C++. You
can't specify one in C#. You can't specify one in Java. Off-hand, I can't
name a language that both has a first-class constructor concept (Rust's
"new" idiom does not count) and specifies a return type on it.

It would naturally follow that, yes, you can't specify a constructor
return type in PHP either, just like we enforce right now. Unless we have
some strong reason to deviate from standard behavior that I do not see?

Regards,
Nikita

Do those languages allow to return something from the constructor (as does
PHP currently)? because I’m more interested in the semantics of : void
than the exact way to have it.

Ah, so that's what this is about! In that case, I'd be happy to simply
always enforce that __construct() cannot return a value, in the same way we
do for ": void" functions. (If we have backwards compatibility concerns, we
can add this as a warning instead of hard error.)

Nikita

5 years ago by Gabriel Caruso — view source — reply

unread

On Tue, Apr 14, 2020 at 7:45 PM Claude Pache claude.pache@gmail.com
wrote:

Le 14 avr. 2020 à 18:53, Nikita Popov nikita.ppv@gmail.com a écrit :

On Tue, Apr 14, 2020 at 6:07 PM Claude Pache claude.pache@gmail.com
wrote:

Le 14 avr. 2020 à 16:54, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :

I'm just not sold on allowing "void" on __construct, because the very
concept of a return type on a constructor is ... void, and also because of
the code style choices this will open (and the CS "wars" I mentioned).

This issue is not specific to magic method like __construct(). It is the
whole concept of “void” as return type which is, say, “problematic”.

In fact, “void” is not really a return type. It is a way to state that
the method is not supposed to return anything, which means, as you said
very well, that “the very concept of return type on [this method] is void”.

That might be a reason to reject the concept of “void” as return type.
Or to revive https://wiki.php.net/rfc/allow-void-variance <
https://wiki.php.net/rfc/allow-void-variance>; . But again, the issue is
orthogonal to the fact that this particular method is magic, and we should
not cherry-pick and reject the concept of “void” for __construct() and
similar magic methods only.

Constructors not having a return type is standard behavior across most
(all?) languages. You can't specify a constructor return type in C++. You
can't specify one in C#. You can't specify one in Java. Off-hand, I can't
name a language that both has a first-class constructor concept (Rust's
"new" idiom does not count) and specifies a return type on it.

It would naturally follow that, yes, you can't specify a constructor
return type in PHP either, just like we enforce right now. Unless we have
some strong reason to deviate from standard behavior that I do not see?

Regards,
Nikita

Do those languages allow to return something from the constructor (as
does PHP currently)? because I’m more interested in the semantics of : void than the exact way to have it.

Ah, so that's what this is about! In that case, I'd be happy to simply
always enforce that __construct() cannot return a value, in the same way we
do for ": void" functions. (If we have backwards compatibility concerns, we
can add this as a warning instead of hard error.)

Nikita

I'll change the RFC and remove the : void return allowance for
__construct(). Should we do the same for __destruct()?

Nikita, about your suggestion of checking the actual return value of
__construct(), I've mentioned in the RFC that I want to do that for all
the magic methods in a future RFC (
https://wiki.php.net/rfc/magic-methods-signature#future-scope). Do you
think we can follow with that, or no, we should add this check to the
current RFC?

Nicolas, I've improved the RFC document. Let me know if there's anything
else that I need to clarify.

Thanks for the feedback y'all.

Best regards,

5 years ago by tyson andre — view source — reply

unread

Ah, so that's what this is about! In that case, I'd be happy to simply
always enforce that __construct() cannot return a value, in the same way we
do for ": void" functions. (If we have backwards compatibility concerns, we
can add this as a warning instead of hard error.)

I'd approve of that. It'd also be useful to enforce that __construct and other magic methods aren't generators,
and that methods from traits renamed to __construct have the same restrictions.

php > class X{ public function __construct() { yield 2; }}
php > new X();  // nonsense
php > trait T1 { public function f() { echo "In f\n"; return 2; }}
php > class Z { use T1{ f as __construct; } }
php > new Z();
In f

Tyson

5 years ago by Gabriel Caruso — view source — reply

unread

Ah, so that's what this is about! In that case, I'd be happy to simply
always enforce that __construct() cannot return a value, in the same way
we
do for ": void" functions. (If we have backwards compatibility concerns,
we
can add this as a warning instead of hard error.)

I'd approve of that. It'd also be useful to enforce that __construct and
other magic methods aren't generators,
and that methods from traits renamed to __construct have the same
restrictions.
php > class X{ public function __construct() { yield 2; }}
php > new X();  // nonsense
php > trait T1 { public function f() { echo "In f\n"; return 2; }}
php > class Z { use T1{ f as __construct; } }
php > new Z();
In f
Tyson

Hello Tyson,

This falls under the Future Scope of the RFC (
https://wiki.php.net/rfc/magic-methods-signature#future-scope) as checking
for the actual return value of these magic methods would be a larger BC.

For now, only the signatures will be checked.

5 years ago by Gabriel Caruso — view source — reply

unread

On Sun, 5 Apr 2020 at 16:01, Gabriel Caruso carusogabriel34@gmail.com
wrote:

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

As suggested by Mr. Danack, I've added a section to the RFC: RFC Impact,
which lists the cases that would break with this RFC.

Thanks for the suggestion, sir.

5 years ago by Guilliam Xavier — view source — reply

unread

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hello,

Thank you, this seems a sensible thing to add.

Just an interrogation: the following magic methods (from the
documentation) aren't mentioned at all in the RFC:

__sleep(): array
__wakeup(): void
__unserialize(array $data): void
(__invoke is basically untyped)
__set_state(array $properties): object
__debugInfo(): array
Is there a reason for leaving them out?
Related, the RFC mentions that __serialize and __toString already
have a runtime check that they respectively return an array and a
string (when called), but why not check their signature (if typed)
at compile time too (i.e. make https://3v4l.org/ZPrVi an error)?

Regards,

--
Guilliam Xavier

5 years ago by Gabriel Caruso — view source — reply

unread

On Thu, 16 Apr 2020 at 16:22, Guilliam Xavier guilliam.xavier@gmail.com
wrote:

On Sun, Apr 5, 2020 at 4:02 PM Gabriel Caruso carusogabriel34@gmail.com
wrote:

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hello,

Thank you, this seems a sensible thing to add.

Just an interrogation: the following magic methods (from the
documentation) aren't mentioned at all in the RFC:

__sleep(): array

__wakeup(): void

__unserialize(array $data): void

(__invoke is basically untyped)

__set_state(array $properties): object

__debugInfo(): array
Is there a reason for leaving them out?
Related, the RFC mentions that __unserialize and __toString already
have a runtime check that they respectively return an array and a
string (when called), but why not check their signature (if typed)
at compile time too (i.e. make https://3v4l.org/ZPrVi an error)?

Regards,

--
Guilliam Xavier

Hello Guilliam

Magic methods not mentioned in the RFC won't be changed, that's why they
aren't mentioned. The reason is either:

Isn't possible to add checks: the case of __invoke
They aren't really magic methods, but an extension method implementation
(as far as I understood during the development of this RFC)

__unserialize and __serialize should be possible to add these checks,
I'll take a look in the implementation.

About __toString: this check is already performed in PHP 8.0:
https://3v4l.org/jIg7b/rfc#git-php-maste
https://3v4l.org/jIg7b/rfc#git-php-masterr

5 years ago by Gabriel Caruso — view source — reply

unread

On Thu, 16 Apr 2020 at 16:22, Guilliam Xavier guilliam.xavier@gmail.com
wrote:

On Sun, Apr 5, 2020 at 4:02 PM Gabriel Caruso carusogabriel34@gmail.com
wrote:

Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso

Hello,

Thank you, this seems a sensible thing to add.

Just an interrogation: the following magic methods (from the
documentation) aren't mentioned at all in the RFC:

__sleep(): array

__wakeup(): void

__unserialize(array $data): void

(__invoke is basically untyped)

__set_state(array $properties): object

__debugInfo(): array
Is there a reason for leaving them out?
Related, the RFC mentions that __serialize and __toString already
have a runtime check that they respectively return an array and a
string (when called), but why not check their signature (if typed)
at compile time too (i.e. make https://3v4l.org/ZPrVi an error)?

Regards,

--
Guilliam Xavier

The RFC has been updated with the missing methods.

If there are no further requests or comments, I'll open this RFC for voting
next Friday.

5 years ago by Dan Ackroyd — view source — reply

unread

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

5 years ago by Gabriel Caruso — view source — reply

unread

On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso carusogabriel34@gmail.com
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,

5 years ago by Gabriel Caruso — view source — reply

unread

On Fri, 1 May 2020 at 13:06, Gabriel Caruso carusogabriel34@gmail.com
wrote:

On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso carusogabriel34@gmail.com
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