Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114807 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51061 invoked from network); 10 Jun 2021 07:16:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Jun 2021 07:16:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 445A31804DB for ; Thu, 10 Jun 2021 00:32:07 -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-Virus: No X-Envelope-From: Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 ; Thu, 10 Jun 2021 00:32:06 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id p17so1633583lfc.6 for ; Thu, 10 Jun 2021 00:32:06 -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=0K80hTHYtjX7KkzGCwBqo9tSSecraXXQ6Ruiq7vxfIM=; b=ioI8biX0VONwUu1vus9fWOUP5oZVDlfiDL60U1zja3B9prpvDIq/mG0qESqzKD/Ern bwiJr2nKcyur4UYjjxjyobXRwLaYZUgV4cAquPiz6RTqgVSBkJmySE9QDK2sIR14+zfz uOgCnkwSkVplI/BY4bj8qL+ht0rK8MhbmiFq9ulPonMPLPBSTD3fNmRIcgWxzTPIshdM Iggw2coJCxau4c3Lxa1Nqgwg7/tpe1EeFAjhUX0olBGD2LBi52TWZ5jb5JQFwlCuOcbo PaVnIU4/+uXPFcGmq+yQnJepouudegZ9WnoNnYgUGZqCs/VQYVDPjgbe3dl7/aiK91R5 6I0g== 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=0K80hTHYtjX7KkzGCwBqo9tSSecraXXQ6Ruiq7vxfIM=; b=m5uscTc2VKL7q2Xkr//5z3dkrY6OfdgxZc8tA/u53V6R+IXXjZAGkPbyWuXuyyBs7m C4vDSSZsdMvNShG0g1sFn2F/LvWYf/3fnZQJd8ghfru2Vix3GKRKExs9uNn1pB6Ke/rs 68yC3ZzO3tYcn8KRtsBEQvdvAj/iirGhSLKRGSVEkoXCT4Is16WfoX/PZW+xiA24aCSD 589nWDHg+yjxZF+qeRB+VWmJYKWNN42Iwsc6nTy8cWcb6rHA/s7OWnOOwVIURKwUiId1 qHzKmBR0sf+E/j0ofT9urYqM85nvjCk5cn9h2VaVi/PoMQ6InrVST7Xu8FSkfcvGK2z5 lFAQ== X-Gm-Message-State: AOAM5320vVXU3CuoEvyLC4L3fn5lFFsPz65o2M1GE2Yz0631dALVcTNn MdM/ZzZMoe+O4fRd9p2Kkvd2lPH+GqLl2Ox+Q6o= X-Google-Smtp-Source: ABdhPJyLkoN/vvO4GuGqTqFZ09oSzGOFlGYS4p59sm2m5xCMe/JJlmMSziH13OpoD+sdzMyCfKpAbwfTZaVgH+2hjiQ= X-Received: by 2002:a05:6512:70d:: with SMTP id b13mr1031427lfs.315.1623310325288; Thu, 10 Jun 2021 00:32:05 -0700 (PDT) MIME-Version: 1.0 References: <7a40dd68-6e44-4b2a-83e2-956fe00c9e6e@www.fastmail.com> In-Reply-To: Date: Thu, 10 Jun 2021 09:31:49 +0200 Message-ID: To: Pierre Joye Cc: Larry Garfield , php internals Content-Type: multipart/alternative; boundary="0000000000004c94b105c46463ca" Subject: Re: [PHP-DEV] [RFC] Readonly properties From: nikita.ppv@gmail.com (Nikita Popov) --0000000000004c94b105c46463ca Content-Type: text/plain; charset="UTF-8" On Thu, Jun 10, 2021 at 3:21 AM Pierre Joye wrote: > Good morning Larry, > > Thank you. Very good summary, maybe worth adding to the RFC :) > > On Wed, Jun 9, 2021 at 11:52 PM Larry Garfield > wrote: > > > readonly would be a separate, independent feature/syntax. > > Yes, my thought is about self explanatory syntax matching common usage > of the same syntax/keyword with other languages. In this case, > readonly, it does not :) > > Absolutely not a big deal (one will google that more ;), however I do > like some "consistency" across languages as we almost all rely on many > and get used to syntax for very standard operations like this. > The usage of "readonly" as proposed follows the commonly accepted interpretation in other languages (modulo details). Readonly properties refer to properties that only allow initializing assignments, though what exactly that means is language dependent (e.g. it can take the form of "only assignments inside the constructor"). Both C# and TypeScript use "readonly" in this manner. I'm not sure where you got the strange idea that "readonly" can refer to asymmetric visibility. The two syntactic approaches to asymmetric visibility that I'm aware of are "{ get; private set; }" in C# and "public private(set)" in Swift. Neither use the "readonly" terminology for this purpose. Using "readonly" to describe asymmetric visibility is semantically incorrect, as such properties are not, in fact, read-only. Regards, Nikita --0000000000004c94b105c46463ca--