Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114393
Date: Tue, 11 May 2021 16:48:23 +0200
To: Sara Golemon <pollita@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals
	<internals@lists.php.net>
Message-ID: <1620744503.110454.6@gmail.com>
In-Reply-To: 
 <CAESVnVpq+AZhnzUN4-6HJs2D66YiQjyMPedTaQP1X0QdwhxiSA@mail.gmail.com>
References: <1620635361.9147.0@gmail.com>
	<CAF+90c8BH6Tnc3L0qg_0gk9d_hEGM2hSP+_4sQ5mOwRasEcQqA@mail.gmail.com>
	<1620728274.110454.3@gmail.com>
	<CAF+90c_kYPdCGkBD9g2Zq3DZ4E0qRvctJ9Vdpr_T-OWkMx-ckA@mail.gmail.com>
	<CAAEi=BO_juw-Cn+jUmL30_JDhZh22EqwWgrrWtJz=vF8Y5K7=Q@mail.gmail.com>
	<CAESVnVpq+AZhnzUN4-6HJs2D66YiQjyMPedTaQP1X0QdwhxiSA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-tzcCO5qMzUOeG/GTTyel"
Subject: Re: [PHP-DEV] [RFC][Draft] Body-less __construct
From: mrtreinis@gmail.com (=?UTF-8?b?TWF0xKtzcw==?= Treinis)

--=-tzcCO5qMzUOeG/GTTyel
Content-Type: text/plain; charset=iso-8859-4; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Sara,

 > While it's certainly silly/pointless to have a nil constructor when=20
there are non-promoted args present, I think that deliberately making=20
that mode special (read: inconsistent) is the wrong way to go.

Sorry, but I don't follow - so you would prefer that this:

    public function __construct();

be valid syntax as well, considering within the scope of the proposed?=20
Am I reading this right?

- Mat=EFss

On Tue, May 11, 2021 at 09:33, Sara Golemon <pollita@php.net> wrote:
> On Tue, May 11, 2021 at 5:18 AM Mat=EFss Treinis <mrtreinis@gmail.com=20
> <mailto:mrtreinis@gmail.com>> wrote:
> > Yes, just to clarify the scope of my initial proposal, this should=20
> only
> > ever apply to promoted constructors that have 1 or more promoted
> > parameters, and no not-promoted parameters.
> >
>=20
> Hard disagree. While it's certainly silly/pointless to have a nil=20
> constructor when there are non-promoted args present, I think that=20
> deliberately making that mode special (read: inconsistent) is the=20
> wrong way to go.
>=20
> > These would NOT be considered valid:
> >     public function __construct();
> >
>=20
> For example, Niki's reply showed a place where that mode is perfectly=20
> reasonable (singleton finals).  If you must have this syntactic=20
> sugar, then please make it consistent.
>=20
> > as well as anything not related to __construct.
> >
>=20
> I'd be willing to go along with inconsistency since once you allow=20
> syntax you can't unallow it without pain. So while I don't love the=20
> tack, I'll follow it if we do this feature. (which IMO we shouldn't).
>=20
>=20
>=20
> On Tue, May 11, 2021 at 8:59 AM Mat=EFss Treinis <mrtreinis@gmail.com=20
> <mailto:mrtreinis@gmail.com>> wrote:
> > If there are no super strong arguments on why this should not=20
> happen or go
> > to RFC, I will draft a RFC and from there, the usual process=20
> applies.
> >
>=20
> I think you've heard a number of strong arguments why it should not=20
> happen, but I also think this deserves its chance to be fleshed out=20
> and voted on, so by all means, do work the RFC.
>=20
> -Sara

=

--=-tzcCO5qMzUOeG/GTTyel--