Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111177
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWy4C0ng5SnEBM6SybcyvO0+MPiHcVcEvDrFG4fNsf2Opw@mail.gmail.com>
 <CAEPJdu=H1j4C8TvdQF=dbMSKUUM=1-3hVkPf1f3WU-hZgKiy8A@mail.gmail.com>
 <VI1PR02MB4703F7E73D33AF4390337E6DE2770@VI1PR02MB4703.eurprd02.prod.outlook.com>
 <CAF+90c_SY8Hd5ChPM+EtDU6JZgBCjHOYvSq81QHpz9eLnXSDRA@mail.gmail.com> <CAESVnVqy3ovC1a6GaWJOrThYmk=LmbjfEw-+v7muToHEyUsFKw@mail.gmail.com>
In-Reply-To: <CAESVnVqy3ovC1a6GaWJOrThYmk=LmbjfEw-+v7muToHEyUsFKw@mail.gmail.com>
Date: Fri, 24 Jul 2020 16:56:47 +0100
Message-ID: <CABHuAWyg93uSVJ3ksrOtrFmGm29+-uE72C00RgfLbgsvKkhT8w@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Bob Weinand <bobwei9@hotmail.com>, 
	Benjamin Eberlei <kontakt@beberlei.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e27fcb05ab3205cd"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: t.carnage@gmail.com (Chris Riley)

--000000000000e27fcb05ab3205cd
Content-Type: text/plain; charset="UTF-8"

On Fri, 24 Jul 2020 at 16:41, Sara Golemon <pollita@php.net> wrote:

> On Fri, Jul 24, 2020 at 10:10 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > > > You added PHP 8.0 as a proposed version, but that will not be
> possible
> > > > anymore 2 weeks of discussion + 2 weeks of voting are not possible
> to fit
> > > > in before the feature freeze, which is in 11 days.
> > >
> > > While you are technically correct, the primary point of a feature
> freeze
> > > is not allowing in completely new features.
> > > It will always happen that there are changes and extensions to RFCs
> > > introduced for the next version which may need to be addressed first,
> > > because there is massive benefit to the new feature in that case.
> (from a
> > > backwards/forwards compatibility standpoint for example)
> > >
> > We should of course be open to making minor adjustments due to
> > unanticipated issues after feature freeze -- after all, that's where we
> > gain experience with new features. The emphasis here is very much on
> > *minor* and *unanticipated* though.
> >
>
> Endorsing this.  Anything post FF needs to be held to a high standard.
> Minor and Unanticipated changes.
> * The option to set alt-names on parameters is substantial.
>  * Making named params explicitly opt-in is less substantial (though
> certainly not trivial), especially if it were hung off an attribute which
> would mean no actual new syntax, but Niki's point that it wasn't an unknown
> or unanticipated issue stands.
>
> I share OP's worry that this pushes workload onto library and framework
> maintainers, and I wouldn't look forward to the review of all APIs to make
> sure their names are correct, but the vote has spoken.  We should
> absolutely continue pursuing this topic with an eye to 8.1 so that library
> updates are less painful moving forward.
>
> -Sara
>

Hi,

My main concern with named params as they currently stand is that they are
fully enabled: if we release PHP 8.0 with named params as they are now,
there's no take backsies. Fixing the polymorphism issue and the maintenance
issues become much harder as you have to work around the fact that there
will be userland code relying on the feature as shipped. If we target
fixing this in 8.1 we would lose the option of being able to make named
params explicitly opt in and as such any possibility of a strict solution
to the polymorphism issues that it throws up.

Regards,
Chris

--000000000000e27fcb05ab3205cd--