Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110786 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44455 invoked from network); 29 Jun 2020 18:15:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Jun 2020 18:15:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D53011804E2 for ; Mon, 29 Jun 2020 10:04:22 -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=-0.2 required=5.0 tests=BAYES_20,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-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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 ; Mon, 29 Jun 2020 10:04:22 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id p20so17266691ejd.13 for ; Mon, 29 Jun 2020 10:04:22 -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=HrbEzP6o6936oWR2CrRLR0O9ChCTBR+cql7OedyhKMo=; b=RhG0bUPWRbLmB8UGefEpLy1M5fx8Bt5x5w79cs17E73ud3ourpRwzTPGSw3KzNFFQE O3v9Js4mmSGIcXqMyQFvU1kjfuTW1N6RevR4qpWMloGhSSPSGEz+ncdxwv+700E9P0vU p7FcJb1d4qEkMUZpNFHBQOxVl/eXgqEyNqzxkhR8t5XMeFmxc7WNWHfLVKQJwQnzEhah AQrxc9xqVxmjK6XY8ddl7d+m/5t4EFAoE765/I4NDwWmnQ2LHpVkVaGIvJI+bB0K7Ax5 1i1rAMTw5n5qsAGkyZ+is1L4BFlPY/yqHK8K5vbJLrFiAVyFnJDS4cXnRBn1VeDH8ItG 5xgA== 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=HrbEzP6o6936oWR2CrRLR0O9ChCTBR+cql7OedyhKMo=; b=jh+UhAo5EaIH3syzuy9y9JbytOFCeRM+VrJzim/x9ZGjKeaHjL7AtXnIJswQ9pBP8r dgm7XhnfmFVraUtOv2YJlknY2m2x1bzPiAojxSLcYOpKIHrjf+bXBatJlrh06ph2OZ1o ZTUcZK2CTRaC1PVgQ8tEkSFFoZoEX4+HlrQUgdY2NUfPTPv8up/a34l9Lg95AwKBxYhn kpLX5J5NKd156FOTJjMV4i2f2ST0raHUY8wBrAK7ii5rmhqxkLscfOM0bUquTFtOxXs6 3w9gTUbu4Nqx48pZmxXgs2LVaeV/SvebAPr6aBE65N9l3X76+/gAcIaGKCvM+RaQFw17 vvVQ== X-Gm-Message-State: AOAM5338Hvcp2sqf5QM/LkVCoDmS5hdMV54C68N+HtfoGSzNz8NK1jmk MdBRuz4c/3pWcEqvUnTWQXurHB5o1S50Zwkay0h+uK39IU8= X-Google-Smtp-Source: ABdhPJwQRaxpy7SV60AfoKZp0jE8mUxKS45HYjPufWJGRlrGeMfkkLMDDoyuD/0JeAwYSuMgFS7UKbHxDt2b9p1GwvY= X-Received: by 2002:a17:906:a459:: with SMTP id cb25mr14720402ejb.234.1593450261299; Mon, 29 Jun 2020 10:04:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 29 Jun 2020 19:04:09 +0200 Message-ID: To: =?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?= Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000cac75305a93c0c93" Subject: Re: [PHP-DEV] [RFC] Property write visibility From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000cac75305a93c0c93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I'd like to start discussion on a new RFC proposing a way to be able to > (optionally) specify property > write visibility, separate from read: > > https://wiki.php.net/rfc/property_write_visibility > > This enables readonly, write-only and immutable like semantics for PHP's > properties. > > These are the common use cases where users tend to resort to magic method= s > or setter/getter > methods. This proposal will as such avoid unnecessary boilerplate, makes > coding easier and more > ergonomic, and in the case of magic method usage improve performance. > Thanks, Andr=C3=A9, I really like it. I feel like it perfectly fits the runtime visibility model of PHP. The RFC could have some words to tell how this would behave when considering the existing magic accessors. We should also define the behavior when creating a reference (write access should be granted, isn't it?) and when unsetting a property. I'd like to share three more points to the discussion: 1. The previous RFC(s) shocked on a conflict between purity declarations (immutable/readonly) and the effective need for mutability in e.g. cloning operations. My experience in PHP is that keywords are strong guidelines but should never be hard blockers: PHP is a runtime scripting language and some of its power and flexibility comes from that, e.g. being able to use reflection sometime to read/write a property in a "friend" scope. "final" is the canonical contra-example of an imperative keyword that blocks legit use cases (e.g. inheritance proxies) I understand why some ppl want immutable/readonly hard guarantees. I think those are nice goals, and I also think that they are better solved by attributes/annotations. These features fit compiled languages. In PHP, they fit static analyzers. There are great ones already and they do a really good job. 2. In other answers, I'm seeing questions about private(isset)/private(unset) in addition to just read+write dissociation. I'm not sure this makes sense: once a property is declared, "isset-accessibility" is fully covered by "read-accessibility". Same for "unset-accessibility": it's included in "write-accessibility". Clarifying how magic accessors would work in the RFC should help solve this branch of the discussion. 3. About accessors, they look like another topic to me. I'm not seeing the need for accessors at all actually. You might disagree, but my point is: that's another topic. We don't need to agree on the usefulness of accessors to decide that this RFC provides actionable value that would benefit the ecosystem. Being able to enforce an externally-immutable-but-internally-mutable state is already a lot of value, I know where I would leverage it immediately. About the syntax, the proposed one looks quite effective to me. It's new, we need to get used to it. This should come fast given how simple it is. TL;DR, I fully support the RFC :) Nicolas --000000000000cac75305a93c0c93--