Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107200
MIME-Version: 1.0
References: <CAF+90c99ftVY4KndJAH_851sEAF===4iyUgSqrc3nEsL833BhQ@mail.gmail.com>
 <CAPCPP0NGJEd=GaRe0q9wJ3jkSDT4-ZQD4YpH2HV0nNv+ECDoGA@mail.gmail.com>
In-Reply-To: <CAPCPP0NGJEd=GaRe0q9wJ3jkSDT4-ZQD4YpH2HV0nNv+ECDoGA@mail.gmail.com>
Date: Wed, 18 Sep 2019 13:11:57 +0200
Message-ID: <CAH0Uv3GS9a56aSPACk2aC5Za+2EuRq2eu2MBOEDBWcWNAtQvAg@mail.gmail.com>
To: jmquarck@gmail.com
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Adding return types to internal methods (PHP 8)
From: andreas@dqxtech.net (Andreas Hennings)

I am not a voting member, but I agree with Sara Golemon.
This is just too big a BC break.

I had similar questions in my own projects, and always chose to find a
solution that does not break BC.

The strategy was:
- Keep existing classes and interfaces stable.
- Introduce new classes or interfaces if I need to change the contract
in a BC-breaking way.
- Where possible, use inheritance to bridge old vs new.

Interface Named {
  function getName();
}

interface NamedV2 extends Named {
  function getName(): string;
}

This can lead to namespace clutter, but it is the responsible thing to
do to allow sustainable evolution.

The "*V2" suffix could be replaced with namespaces, e.g.
"PHP\\8\\Named" vs "PHP\\9\\Named".
Then perhaps there could be some magic to make all symbols from
"PHP\\8" available in "PHP\\9" as well, even if they are not
overridden.

-- Andreas

On Wed, 18 Sep 2019 at 11:00, <jmquarck@gmail.com> wrote:
>
> Hi internals,
>
> I appologise for writing here without warning, and without being an activ=
e
> 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 o=
r
> a tweet thread looked unfair to me.
>
> About all these RFC discussions and the PHP evolution, from the outside i=
t
> 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 featu=
re
> 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 h=
ow
> 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 th=
is
> looks is demoralizing when the whole RFC process should be invigorating f=
or
> 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 migh=
t
> 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.ppv@gmail.com> del dia dg., 11 d=E2=80=
=99ag. 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-f=
inal
> > 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 st=
ring
> > 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 thei=
r
> > minimum requirement to PHP 8 when adding the return type: They can stil=
l 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
> >