Re: [PHP-DEV] [RFC] Adding return types to internal methods (PHP 8)
Hi Nikita and Nicolas,
After a month of pause, I came back to this topic.
A concern I have is that for methods with union return types, there
> wouldn't be any way to avoid a deprecation warning without having PHP 8 as
> the minimum version requirement. And given PHP's general error handling
> story, deprecation warnings are not exactly graceful...
>
Thanks for pointing out this possible consequence. I do agree that it's a
valid concern, so we should try to do something about it. I could come up
with a few possible mitigations so far:
- instead of E_DEPRECATE, we could emit E_STRICT warnings so that people
can separately tackle this class of errors from the rest
- we could add support for a SuppressReturnTypeDeclaration annotation that
could suppress these notices altogether
- we could postpone the tentative declaration of those method return types
which can't be expressed on PHP 7.4 to a later version (e.g. PHP 8.4) when
the 7.x series will have become EOL for a while
Actually, I counted how many of the return types in question can't be
expressed on PHP 7.4. I found ~270 results out of all the ~1440 methods
which don't yet have a return type declared.
Do you think these ideas would sufficiently answer your concerns?
Is there any way we could make this mechanism more broadly available than
> just for internal methods? This is a problem that also shows up when adding
> return types in userland libraries.
Inspired by Symfony's strategy, a #[ReturnTypeDeclaration("int|string",
"Library Foo v2.0 will declare int|string as return type")] attribute could
be added to methods in order to gradually
let any child classes know that a future version of library Foo will
declare the int|string return type for the method in question. Then
overriding methods should either declare some kind of
return type (unfortunately, even a wrong one would suffice, since it would
be cumbersome to store exact type information in an attribute, if I'm not
mistaken) or add the very same
attribute - but at least the first argument should be exactly the same,
from character to character - if people want to avoid the deprecation
notice.
It has just come to my mind that in case of internal functions, we could
combine the annotation based approach described above together with the
behavior I originally proposed:
- if an overriding method declares a return type then the regular
compatibility checks would kick in, and a notice would be emitted in case
of failure
- if an overriding method doesn't have a return type, but
a ReturnTypeDeclaration attribute, then a notice would be emitted if the
attribute doesn't have the exact same type as the
one we added via PHPDoc in the stubs
- otherwise a notice is emitted
To be honest, this migration path seems to be slightly overcomplicated for
me. So personally, I would be just fine with the ideas I collected in the
beginning of my message for reducing impact.
However, if you think that it makes some sense, I'm ok with going with
something along the lines of it.
Regards:
Máté
Re: [PHP-DEV] Re: Proposal: namespace the SPL
On Sat, Feb 13, 2021 at 10:57 AM Pierre R. wrote:
>
> Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit :
> > You make some good points, Pierre. Here are my main rebuttals:
> >
> > 1. "Spl" is already the effective namespace for the SPL because
> > that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so
> > on. Its namespace has already been de facto chosen.
> >
> > 2. We have two proposals adding new things to the SPL for 8.1, so we
> > need to decide if they are going into ext/spl as 1. \Spl\Thing, 2.
> > \SplThing, or 3. \Thing. Keeping the wider vision in mind is a great
> > principle, but we need to decide on these new additions _now_ despite
> > not reaching consensus on the wider thing.
> >
> > Obviously, I'm hopeful we can agree on using the Spl namespace for
> > these additions, and any future SPL additions.
> >
> >[1]: https://wiki.php.net/rfc/any_all_on_iterable#vote
>
> Aside of the fact I don't like "Spl" if a good naming convention comes
> out with it prefixing all namespaces so be it and I'll be happy. One
> thing that bother me much in the current proposal is those kind of
> classes: `Spl\FixedArray -> SplFixedArray`.
>
> That's the most important point in my eyes, it should be already named
> with a deeper namespace, such as:
>
> `Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}`
>
> in order to make space for later other namespaces to take their rightful
> place, such as:
>
> `Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or
>
> `Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`.
>
> Even if it starts with a narrow scope, it *must*, in my opinion, make
> space for later additions, therefore `Spl\` must be considered as being
> the "PHP standard library root namespace", in that regard, no classes or
> functions must live at root, they must be segregated in their own
> sub-namespace. If we don't do this, we will very much regret it later.
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
To be clear, I am arguing that `Spl` be the namespace for future
additions to `ext/spl`, and that we alias a few existing types for
consistency. Just as `ext/spl` is not the whole PHP standard library
(just one small part of it), the `Spl` namespace I am proposing is not
the "PHP standard library root namespace" either; it's just the
namespace for the bits in `ext/spl`.
What you are arguing for was the subject of recent namespacing
proposals, which failed to reach consensus. I am intentionally
proposing a different solution for a much narrower problem hoping it
will stick, so that new additions going into the ext/spl can avoid
having this naming discussion every time.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal: namespace the SPL
Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit :
You make some good points, Pierre. Here are my main rebuttals:
1. "Spl" is already the effective namespace for the SPL because
that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so
on. Its namespace has already been de facto chosen.
2. We have two proposals adding new things to the SPL for 8.1, so we
need to decide if they are going into ext/spl as 1. \Spl\Thing, 2.
\SplThing, or 3. \Thing. Keeping the wider vision in mind is a great
principle, but we need to decide on these new additions _now_ despite
not reaching consensus on the wider thing.
Obviously, I'm hopeful we can agree on using the Spl namespace for
these additions, and any future SPL additions.
[1]: https://wiki.php.net/rfc/any_all_on_iterable#vote
Aside of the fact I don't like "Spl" if a good naming convention comes
out with it prefixing all namespaces so be it and I'll be happy. One
thing that bother me much in the current proposal is those kind of
classes: `Spl\FixedArray -> SplFixedArray`.
That's the most important point in my eyes, it should be already named
with a deeper namespace, such as:
`Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}`
in order to make space for later other namespaces to take their rightful
place, such as:
`Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or
`Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`.
Even if it starts with a narrow scope, it *must*, in my opinion, make
space for later additions, therefore `Spl\` must be considered as being
the "PHP standard library root namespace", in that regard, no classes or
functions must live at root, they must be segregated in their own
sub-namespace. If we don't do this, we will very much regret it later.
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal: namespace the SPL
On Sat, Feb 13, 2021 at 9:25 AM Pierre wrote: > > Le 11/02/2021 à 18:48, Chase Peeler a écrit : > > I think Spl makes sense (there might be a debate over whether it should be > > Spl or SPL though). How feasible is it to create generate a deprecation > > notice when the global version is used? I assume the hope is to eventually > > move away from using those, and I don't think that's a horrible BC break > > given that users have enough time to prepare for it. > > Hello, > > For what it worth, I think that Spl is both ugly to read (yes, I like > things not only to be semantic, but elegant as well) and hard to type on > my keyboard (OK subjective point here, both are actually). > > "Spl" does mean somethings, but I'd prefer something more generic such > as "std" or "standard" or "system", or even "stdlib". And it's an > opinion, and we all have one. Even having lowercased namespace names for > PHP standard library wouldn't bother me much: it would make it > consistent in reading (e.g. `use std\array\first` for example, vs > \array_first()` vs `use Spl\Array\first`). OK stupid point here, but > fact is I don't really care, I just try to make a point here: we are > free to invent new things, or get old things from other languages. We > have all the possibilities of the world and beyond offering themselves > to us, the only limit is our imagination. > > I disagree about narrow scope: if we / you don't think about the future, > each narrow iteration will only get more and more inconsistent, each > step will be a flame ware about naming, and no convention or consistency > will emerge. And it will be slow. I will retire before I'll see an Array > class or a `collection` namespace. And I'm not even that old! This will > fatigue people, and kill any kind of good faith or good sense we still > yet have. > > I think that namespacing, even if its implementation starts narrow (this > make sense) should be thought thoroughly with a wider scope, with a > global scheme even more. It should be voted with a complete view of what > it will become, and how that makes stuff consistent across the whole > actual and future SPL. > > I know this has not much chances to happen, because people always > disagree for purely subjective reasons (beauty of names, ease of typing, > semantic meaning of stuff, weird keyboard layout, or just because some > people don't like when it's other people's ideas which get to be chosen > or voted for) anyhow, I think that narrow scope will only gets PHP > standard library farther from its goal than help it. > > This was my 2 cents, > > Best regards, > > -- > > Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > You make some good points, Pierre. Here are my main rebuttals: 1. "Spl" is already the effective namespace for the SPL because that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so on. Its namespace has already been de facto chosen. 2. We have two proposals adding new things to the SPL for 8.1, so we need to decide if they are going into ext/spl as 1. \Spl\Thing, 2. \SplThing, or 3. \Thing. Keeping the wider vision in mind is a great principle, but we need to decide on these new additions _now_ despite not reaching consensus on the wider thing. Obviously, I'm hopeful we can agree on using the Spl namespace for these additions, and any future SPL additions. [1]: https://wiki.php.net/rfc/any_all_on_iterable#vote -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal: namespace the SPL
Le 11/02/2021 à 18:48, Chase Peeler a écrit : I think Spl makes sense (there might be a debate over whether it should be Spl or SPL though). How feasible is it to create generate a deprecation notice when the global version is used? I assume the hope is to eventually move away from using those, and I don't think that's a horrible BC break given that users have enough time to prepare for it. Hello, For what it worth, I think that Spl is both ugly to read (yes, I like things not only to be semantic, but elegant as well) and hard to type on my keyboard (OK subjective point here, both are actually). "Spl" does mean somethings, but I'd prefer something more generic such as "std" or "standard" or "system", or even "stdlib". And it's an opinion, and we all have one. Even having lowercased namespace names for PHP standard library wouldn't bother me much: it would make it consistent in reading (e.g. `use std\array\first` for example, vs \array_first()` vs `use Spl\Array\first`). OK stupid point here, but fact is I don't really care, I just try to make a point here: we are free to invent new things, or get old things from other languages. We have all the possibilities of the world and beyond offering themselves to us, the only limit is our imagination. I disagree about narrow scope: if we / you don't think about the future, each narrow iteration will only get more and more inconsistent, each step will be a flame ware about naming, and no convention or consistency will emerge. And it will be slow. I will retire before I'll see an Array class or a `collection` namespace. And I'm not even that old! This will fatigue people, and kill any kind of good faith or good sense we still yet have. I think that namespacing, even if its implementation starts narrow (this make sense) should be thought thoroughly with a wider scope, with a global scheme even more. It should be voted with a complete view of what it will become, and how that makes stuff consistent across the whole actual and future SPL. I know this has not much chances to happen, because people always disagree for purely subjective reasons (beauty of names, ease of typing, semantic meaning of stuff, weird keyboard layout, or just because some people don't like when it's other people's ideas which get to be chosen or voted for) anyhow, I think that narrow scope will only gets PHP standard library farther from its goal than help it. This was my 2 cents, Best regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Inline conditional that returns null if falsy
Em sáb., 13 de fev. de 2021 às 00:11, Marco Pivetta escreveu: > Hey David, > > Even upfront, this looks like a quite bad idea: either you have an empty > collection, or you have a collection with elements in it, but `null` is a > very different concept that isn't homogeneous with the resulting type. > > I've updated multiple projects in the past where `array|null` was used as > return type for a collection-alike endpoint, removing `null` and replacing > it with an empty iterable instead. > This was just one of the examples I have, but I still think it is valid. Creating an empty collection costs resources that could be avoided in situations where null could be used (as is most of my real use cases). But there are other situations where we can use different situations to use this type of resource. One of the examples I have is when I need to include a class in an HTML element conditionally. There are probably better ways, but this is a quick one for simple situations: ... vs. ... It is much easier to read, and I believe that the cost for language would be minimal, and perhaps even more optimized than the use of ?:. Atenciosamente, David Rodrigues Em sáb., 13 de fev. de 2021 às 00:11, Marco Pivetta escreveu: > Hey David, > > On Fri, Feb 12, 2021, 20:24 David Rodrigues > wrote: > >> Hello! >> >> It is just a suggestion to be discussed. >> >> A lot of places on my projects I have codes like: >> >> $companies = $user->companies->count() >> ? new Collection($user->companies) >> : null; >> > > Even upfront, this looks like a quite bad idea: either you have an empty > collection, or you have a collection with elements in it, but `null` is a > very different concept that isn't homogeneous with the resulting type. > > I've updated multiple projects in the past where `array|null` was used as > return type for a collection-alike endpoint, removing `null` and replacing > it with an empty iterable instead. > >>
