Hi internals,
I appologise for writing here without warning, and without being an active
member of Internals. But I did not find any other public way to fairly
contribute to the conversation: externals.io, though is claim ("opening
#internals to the outside") is actually closed, and writing a blog post or
a tweet thread looked unfair to me.
About all these RFC discussions and the PHP evolution, from the outside it
seems too petty. In my opinion, PHP lacks of the ambition to pursue a
long-term vision. Any vision would be far better than having none.
Otherwise you just write code, which is actually your job, but without
meaning. What kind of language PHP would like to be? Having a purpose to
accomplish would facilitate RFC priorization, and pull more implication
from people.
A clear mission, a narrow focus, does not necessarily mean a narrow feature
set. Python is an example for this: they decided to fight against Go for
its prominence, and they achieved spreading Python features to data, to
asynchronous, etc. Plenty of old Python contributors recently mentioned how
impossible has become for them to keep on track with all new features
Python provides now. In comparison, PHP walks like the elders.
PHP RFC's may stay as a draft, or under discussion, for years. In 2019 this
looks is demoralizing when the whole RFC process should be invigorating for
the community.
My claim is for you all to leave aside these minor disagreements and
discuss, internally as well as with the community, what that mission might
be. PHP has strengths no other general purpose language has, why not
leverage them?
Actually, this is not the topic for my writing here, but I also suggest
spending some time, or appointing someone, to improve this whole
communication toolset: it is old-fashioned, and stops contribution.
Best.
Jordi Martinez
Missatge de Nikita Popov <nikita....@gmail.com> del dia dg., 11 d’ag. 2019
a les 10:44:
> Hi internals,
>
> Something that came up in the arginfo thread: We can now add type
> annotations for everything, apart from return types on methods of non-final
> classes.
>
> The reason is that adding these return types would require inheriting
> classes to specify them as well. The same problem does not exist for
> argument types thanks to
> https://wiki.php.net/rfc/parameter-no-type-variance
> (which is exactly why we wanted that RFC).
>
> For example, if we add a "string" return type to DateTimeZone::getName(),
> then any userland child of DateTimeZone would also have to specify a string
> return type.
>
> The good news: Userland classes can already specify those types *now*,
> because adding a return type in a child class is legal. This means that if
> we add those return types, userland extensions do not have to bump their
> minimum requirement to PHP 8 when adding the return type: They can still be
> compatible all the way down to PHP 7 (or 7.1, depending on the type).
>
> What do you think about this? As we are currently annotating everything
> with types, and we're at a major version, this would be the ideal time to
> make this change. But there's certainly a BC break here. (And, for the
> record, this is not the type of BC break where P++ or editions help,
> without creating a larger mess.)
>
> Regards,
> Nikita
>
