Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109269 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23441 invoked from network); 24 Mar 2020 13:28:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Mar 2020 13:28:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D982A1804C5 for ; Tue, 24 Mar 2020 04:52:31 -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_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-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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, 24 Mar 2020 04:52:31 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id v4so9240170lfo.12 for ; Tue, 24 Mar 2020 04:52:31 -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=93AQXQkukekw8QzttrSUXP5lNnsT+dWGE27qyjnBlXE=; b=kyugjiwrSQXAaCLvQQJpKFbg3Nd4yW2tPEIJbKTDmeh1UtYH3TZcQtblJZoJsd5lYJ +QcHZT9Zm/cTPeSJVF6Het0+Pw6mviS9uRfuyJMXMmA/xpCf0MTmXn2ICdfEYHiEDLdX Iu+sLeBOhCXAHbnYeAXkBs1F3xhhx3HMYOvHonwxaJA4XkclXZjwaetpF0uo6EwR6WvY DuKK26KPj0t4TFHKx4IiI7U06jMHgy9TiuPf44a74wwO9UsSnym2BdHf1isX76XDCgyk go+G6NNONJ/ODdt3w4AV1+8GXTJsbXS1y1ondNnOPCBr0trgGYnNCmtTBoupmpMeMu1I j9sQ== 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=93AQXQkukekw8QzttrSUXP5lNnsT+dWGE27qyjnBlXE=; b=JGxllPtA0BHj1zeMbiGY/d9NVSFf/IJsEi8N/q8oD89DJt6HalngadXTDt+LWrfB8r H99nRk9f0rpeDylS/OYxn2qKOv/FyLaawSninPYbcCRQWJbPcisTeRilFXJmfg01CPQz AVgei6MZDwxAQom9Ev4w41Y/nOG9C+hbNEi8DBXdBbyV7Rjb5Yt/50EegvrOYd1xH8FY BsCWNEpdCBIv0CNSHa7WjiaaiJ1+spIU0Vo8YNh1oOFtXK1p5eanXGEUdWSATbvs0w58 Ls97IDbos2JRTtJaYm/EBs5Itqm4B7VN+HQKx86U+vGqB5wXDwse4xTVW4FiDFbXvZ// JpYA== X-Gm-Message-State: ANhLgQ1GR7mOgqWpW4piChkj0W+vtYcjQVvbNuDUgGLUkF92tZCm+ef+ vUdQoU7Rbf1q/OSMe6EpLNoaMX8QBiP6xQvZ0Fs= X-Google-Smtp-Source: ADFU+vtXcBkD7vs+RUGqt+vYWagKS7O4EWNDgi5jcD7dmYS7ILT4UerMTPYL2DbiBd7kLDfE5XAH87yFKRvaQE9A3RY= X-Received: by 2002:a05:6512:31d6:: with SMTP id j22mr16220692lfe.173.1585050749526; Tue, 24 Mar 2020 04:52:29 -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: Tue, 24 Mar 2020 12:52:13 +0100 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000e06e3f05a19862cd" Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis From: nikita.ppv@gmail.com (Nikita Popov) --000000000000e06e3f05a19862cd Content-Type: text/plain; charset="UTF-8" On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield wrote: > 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 right > 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 rather > than narrowly-focused one-offs. > > To that end, I have written an extensive analysis of the problem space and > 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 > * Named parameters > * Compound Property Visibility > > For details, see the full writeup: > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics > > Thank you for your attention. > Thanks for the write-up Larry. I like where you're going with this. If we were starting from a blank slate design, I would advocate for: a) having an object initializer syntax b) not having first-class constructors at all c) using named constructors instead. This also happens to be exactly what Rust does, go figure... Unfortunately this kind of approach is hard to retrofit into PHP, because we already have constructors, almost all classes define them, and it's hard to reconcile object initialization syntax and non-trivial constructors in a meaningful way. Combining this with the "no public properties" cargo cult we have inherited from Java, the paradigm shift is probably too large here. If we can't have object initializers, then improving what we can do with constructors is the next best thing :) I generally like the ideal of combining property declaration and constructors. I've had this on my mind for a while already, and also received the same suggestion from a couple of other people (I think Nicolas was one of them?) The current amount of boilerplate that is needed is just large enough that I will often go with a quick and simple ad-hoc array structure rather than declaring an explicit value object type. The main concern, as others have already mentioned, is that these inline declarations can end up being quite verbose, especially once attributes get involved. I think I will write up a quick implementation & RFC for this part, as it seems like something we should at least consider in more detail. Named parameters are a pretty tough topic. I think one of the main points of contention is that they make the parameters names part of the API contract, and as such also subject to LSP. Your proposal offers two possible ways to side-step this: First, by making named parameters opt-in with a special syntax {}. Second, by limiting them to constructors. The latter variant still exposes parameter names in the API, but at least does not require their preservation across inheritance, as constructors are excluded from LSP. I'm somewhat torn on this, because it makes named parameters unusable with the very large body of existing methods, and introduces an inconsistency in which methods can use named params and which don't. Regarding the remainder, I think that all of readonly properties, asymmetric visibility and property accessors have their place and value, with some overlap between them. As you already mentioned, the previous property accessors proposal also included asymettric visibility as a special case, and that's how I would introduce it as well. However, I generally think that the main value really is the readonly properties as proposed in the recent RFC. Nowadays, a large fraction of the classes I use are immutable value objects, for which public readonly properties provide a much closer match to the semantics I want. I think that the problem with with-er methods is just that: It's a problem with with-er methods. It's what happens when you try to shove immutability into something that is not actually being used in an immutable manner. Don't pretend things are immutable when they aren't... Regards, Nikita --000000000000e06e3f05a19862cd--