Re: [RFC][Draft] Body-less __construct
| From: | Chase Peeler | Date: | Tue, 11 May 2021 14:39:39 +0000 |
| Subject: | Re: [RFC][Draft] Body-less __construct | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-114388@lists.php.net to get a copy of this message | ||
On Tue, May 11, 2021 at 10:34 AM Sara Golemon <pollita@php.net> wrote:
> On Tue, May 11, 2021 at 5:18 AM Matīss Treinis <mrtreinis@gmail.com>
> wrote:
> > Yes, just to clarify the scope of my initial proposal, this should only
> > ever apply to promoted constructors that have 1 or more promoted
> > parameters, and no not-promoted parameters.
> >
>
> Hard disagree. While it's certainly silly/pointless to have a nil
> constructor when there are non-promoted args present, I think that
> deliberately making that mode special (read: inconsistent) is the wrong way
> to go.
>
> > These would NOT be considered valid:
> > public function __construct();
> >
>
> For example, Niki's reply showed a place where that mode is perfectly
> reasonable (singleton finals). If you must have this syntactic sugar, then
> please make it consistent.
>
> > as well as anything not related to __construct.
> >
>
> I'd be willing to go along with inconsistency since once you allow syntax
> you can't unallow it without pain. So while I don't love the tack, I'll
> follow it if we do this feature. (which IMO we shouldn't).
>
>
>
I agree. I think making things inconsistent between constructors and other
methods is something that can be lived with - there are already other
things special about constructors that don't apply to other methods - but
we should at least allow consistency among constructors and allow the
trailing semicolon in all cases.
>
> On Tue, May 11, 2021 at 8:59 AM Matīss Treinis <mrtreinis@gmail.com>
> wrote:
> > If there are no super strong arguments on why this should not happen or
> go
> > to RFC, I will draft a RFC and from there, the usual process applies.
> >
>
> I think you've heard a number of strong arguments why it should not happen,
> but I also think this deserves its chance to be fleshed out and voted on,
> so by all means, do work the RFC.
>
> -Sara
>
--
Chase Peeler
chasepeeler@gmail.com