Hey internals,
I wanted to ignite a friendly discussion whether PHP should allow typed callable properties. The problem arises as typed properties RFC did not allow the callable type 1 due to its context-dependent behaviour. As such, for improving the language's consistency and adding support for strict callable typing, I believe we should look into solutions for avoiding this special case. Note that the solutions listed below are taken from the RFC and are thoughts from Nikita Popov, so credits to him. Here is a quick summary of the solutions:
- Ignore the issue. At the moment, this is the behaviour that both parameter and return type hints pose and I believe is also the best option for callable properties. At least for the time being. Generally, this would increase language's consistency and would also ensure that the type is actually a callable. In the worst-case scenario, if the callable is not callable from this context, PHP would still throw a runtime error.
- Take visibility into account. We could allow making only typed protected/private callable properties but this would create a quite tight coupling between the visibility and type. It would also be a special case and therefore a violation of the OCP principle.
- We could automatically wrap assignments to typed callable properties into
Closure::fromCallable(). Though this would worsen the performance and add additional overhead when using the callable type. As Nikita mentioned, if this is the approach we're taking, we should also impose such conversion in every place where the callable type may occur. - Perform type checks when reading. At the moment, we perform type checks only when writing. We could change that and also perform type checks when reading. Although this behaviour would be weird, as we would get a type error when trying to read a typed callable property (e. g.
($this->callback)()would throw a type error).
Best regards,
Benas Seliuginas
P.S.: If no one is interested in implementing this, I would be up for the job if we make a consensus on what approach we should take.
Heya,
Fairly off-topic, just so you're aware. This message arrived in my spam
folder, just like some other messages always do. I get: "pair.com did not
encrypt this message", which I see come by quite often. A lot of messages
from Ilija also ended up in my spam folder and so it did for others. I'd
imagine people will have missed this message.
Regards,
Lynn
Heya,
Fairly off-topic, just so you're aware. This message arrived in my spam
folder, just like some other messages always do. I get: "pair.com did not
encrypt this message", which I see come by quite often. A lot of messages
from Ilija also ended up in my spam folder and so it did for others. I'd
imagine people will have missed this message.Regards,
Lynn
This appears to be happening due to DMARC rules on the domains of the senders. I had the same thing happen to my emails, so I had to relax my DMARC rules. If your rules are set too strict, servers see the From address coming from a server not authorized by the domain, so it gets quarantined.
Cheers,
Ben
Thank you for letting me know! I'm not sure if I can do something though, given that I'm using ProtonMail.
Best regards,
Benas Seliuginas
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Heya,
Fairly off-topic, just so you're aware. This message arrived in my spam
folder, just like some other messages always do. I get: "pair.com did not
encrypt this message", which I see come by quite often. A lot of messages
from Ilija also ended up in my spam folder and so it did for others. I'd
imagine people will have missed this message.
Regards,
LynnThis appears to be happening due to DMARC rules on the domains of the senders. I had the same thing happen to my emails, so I had to relax my DMARC rules. If your rules are set too strict, servers see the From address coming from a server not authorized by the domain, so it gets quarantined.
Cheers,
Ben