Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109222 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 56206 invoked from network); 23 Mar 2020 07:31:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Mar 2020 07:31:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8C7A51804DD for ; Sun, 22 Mar 2020 22:55:29 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 ; Sun, 22 Mar 2020 22:55:29 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id s18so2674081otr.9 for ; Sun, 22 Mar 2020 22:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=veOUpUB/64KiPBagn7rc0cqSafn3ixsq7PNeFN+K/yM=; b=Bxrw27jtGdd+JDcta4HnyBmhjKAUKaZZbJA69gfBCwKFfUmkq2pjKzbVLrSYCnTq8d C+nr5ZvLbH1+mFgFOw3Lw0/054cHg7W8Sk9W1RuUA4YOnvSDlHHKr6s7x9QFpGq45SBQ 9V2/M7T+yFzRsrpASll0phr7wFXgE/F3rQeWlqaCkWME2MNB6l9WRJRuPrAMWX1QJq5K nBFnvd404I+D2wruhD3qEEoymByLG2h7edw6T6lBCJFZUN8F2bsRJnKJBbr8TJ+2Cpod uIwC/e8n0VCeHqIISVoGQDApPo33wOZa50R1UCMR/fxSBF3gJBG4ErB32fUCVESTXlrW pOBQ== 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; bh=veOUpUB/64KiPBagn7rc0cqSafn3ixsq7PNeFN+K/yM=; b=j9zwnZso55VTuUQZTUvLzewbht2Ft9GDe9OgEFEm+xqflRHtEWIRQJDBT8Eq4UFTJe 8u22mac1MarQvtSK13sGIAfJ/LQsH/EUw4fMy5pvFeAdtfDuIuantirLw3N2M3+OhzwA NBWK49cTrNAstw0waI9nj67EzXJwNEl0VO7nIb1JwXB7hJmauW8U8oQAvdovQQPiIWzs j80mlSPgdhlZQhakib402MYZQzFNURCFXy+m60mE3hsm6SYr++tuqgKQMg41bZFjOt3k 7vpot5HzeDouGP9rv6uOl6ogxLhZ3PQIsdBgIOC3cKlRzqf09pOMXYvgZOpBlXLaZppx GBbw== X-Gm-Message-State: ANhLgQ38yxrJbaM6dZWssMAWiIwVzBk5OJcfIH6xujs41yDe3ryaODv5 ocNx8wpSLjbzmYDp1xidBHuHdxcMY7okxvDUsZUhUS+l X-Google-Smtp-Source: ADFU+vs0RMYqaKEalzoxRusbUynuAaXKfNgLS4GvIzYzUHRQXBM42sUk18Z2ssn2BdAMZBNpOnp2TJufYhGu9a0S45A= X-Received: by 2002:a9d:178a:: with SMTP id j10mr8482133otj.182.1584942926452; Sun, 22 Mar 2020 22:55:26 -0700 (PDT) MIME-Version: 1.0 References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com> In-Reply-To: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com> Date: Mon, 23 Mar 2020 06:55:14 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000001edcb105a17f48da" Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=) --0000000000001edcb105a17f48da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Larry, pon., 23 mar 2020, 01:48 u=C5=BCytkownik Larry Garfield napisa=C5=82: > Hi folks. > > There have been a lot of RFCs and possible RFCs of late that are all > circling around the same related problem space: Working with objects righ= t > now involves too much boilerplate to get things done. As I've mentioned > several times, I believe we need to be looking for broader solutions rath= er > than narrowly-focused one-offs. > > To that end, I have written an extensive analysis of the problem space an= d > the current and recent proposals. I've put it on my blog rather than > inline here because it's quite long and the blog offers better formatting= . > > Discussion can happen here, but I'll also respond to comments there. > > In short: I believe our biggest potential win is to focus on 3 RFCs: > > * Constructor Promotion > That still doesn't resolve issue with lot of boilerplate when you deal with small objects for which public readonly is enough like object-initializer could. So I'm not sure about my vote here. It does solve only one narrow situation for me. * Named parameters > What would be nice for methods and functions. +1 * Compound Property Visibility > I didn't get it what benefits over property accessors it could have. > For details, see the full writeup: > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics > > Thank you for your attention. > > -- > Larry Garfield > larry@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --0000000000001edcb105a17f48da--