Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109118 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6186 invoked from network); 18 Mar 2020 04:13:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Mar 2020 04:13:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5B6A21801FD for ; Tue, 17 Mar 2020 19:36:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 17 Mar 2020 19:36:32 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id x143so2805304lff.12 for ; Tue, 17 Mar 2020 19:36:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KygF1BslUyI3OwOmBj1QnnXaFC/fTK0mAicgq9/U/5I=; b=GXovgDzOcrbtHaI4s3kIW/bJMc2uSLyQqc5MgwX+tAdY06ly1PNGFsynx3aoDPJeTP XELSgzs0sgIrQD8Rs+hUN30i7O+GfCbK4zWuFTwFSYNMo2oeUhVrtkEbEwAePT5Uagb4 SQoAbo9Kys4z35myzfqGrnETkN9AGHVRxw7HKFkHS3UDmCexGJaaKkXIO0oFmYHyzlUm EpWc5GS4uBApZkzSjCqUq6/Il5AdvPzdmfDAhNE5MxnTyuSiLV4YGmCX9PoHGJwVxL1b lrCi7scbJUj81WSntOT0B4tLv1CpBxDrih0U4CxRHwXwZtz9WXX9D9veRj4Yx1Eu61Zz 4edg== X-Gm-Message-State: ANhLgQ0DpPo4JR4ikpBQW4m2dPhQI20rJf2KWjYXsRxXrNAzJWrMmvlP NH6si4hNT4CF6765xeD+WYaKewSq8lRnXOX/I6k= X-Google-Smtp-Source: ADFU+vtx4mpKERSUVkbd7lzdArCUWbc2e4nHFKjxsD1HjxGoKMUawf7+psR8dMOnqm9gzTXA6zeUxpQr0E8EvxJw/aI= X-Received: by 2002:ac2:484f:: with SMTP id 15mr1394239lfy.3.1584498990996; Tue, 17 Mar 2020 19:36:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 17 Mar 2020 21:36:21 -0500 Message-ID: To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= Cc: php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment From: jakob@givoni.dk (Jakob Givoni) Thank you, Micha=C5=82, for chiming in :-) On Tue, Mar 17, 2020 at 10:52 AM Micha=C5=82 Brzuchalski wrote: > For object initializer, I was hoping to introduce a feature which with th= e benefits of typed properties > could reduce the boilerplate on initializing object and setting their pro= perties in one expression. Exactly my motivation with COPA as well; - Typed properties - check, - Reduce boilerplate - check, - Initializing and setting properties in one expression - check. > With object initializer, this could be reduced to: > > $this->dispatch(new SomeCommand { foo =3D 'bar', baz =3D false }); And with COPA it would be; $this->dispatch((new SomeCommand)->[ foo =3D 'bar', baz =3D false ]); Subtle differences, when compared to the currently available alternative. > But as mentioned IMO this is a different feature than what you propose an= d personally I see no point > in reducing only assignment statements without combining it with object c= onstruction for these kinds > of small objects, DTO's, commands, queries and events. Maybe you missed that COPA can be combined with object construction? > but personally I don't need a constructor at all in those cases since we > have typed properties and it looks like they could be also marked as read= -only in next major PHP version. Exactly, and as I couldn't help notice that you voted for the Write Once Properties RFC, which clearly states that object construction is a fuzzy term (meaning don't take it too seriously) and lazy initialization is a feature... I hope you will either reconsider your support for COPA or let me know what I'm missing so I can consider other directions.