Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115432 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19198 invoked from network); 16 Jul 2021 07:47:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jul 2021 07:47:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B913E180089 for ; Fri, 16 Jul 2021 01:12:02 -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-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (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 ; Fri, 16 Jul 2021 01:12:02 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id g19so13494817ybe.11 for ; Fri, 16 Jul 2021 01:12:02 -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=MFvvQn8L+RuDdDdY21L8umy0yZn0DIEHRF1buIiyTQs=; b=iiC+gLqe4Wv22H17JVjFzcPEPhFNBV+jUlUWceY7RiSKj0jZxa8MC+bHCoGYJAGg0N vYnaS5e2g0SQLSP/30OipY2nC/BQHcASwnQcfLYk3fI9e/i58aep3/rQ3pY+ZI7JdaRg sbU8X9FZdwKIqPFaViVoWCSv4fOva0N/scA0se+dquCJjSN3gBHhJ520UdMVp1GDBElw 9vfACVdtjmVJZZStMwu8u0W658sfHwW5ccze9EDbS52vMhkEkNolbDqwLmAmA0LmEjku 596KzKJj9X7sx9qvX8jWho91Dpfu9bSL0t3d8lqUlPtLXJuNYxvTvxYxshDhCun2sXUh MTXg== 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=MFvvQn8L+RuDdDdY21L8umy0yZn0DIEHRF1buIiyTQs=; b=emoIssMDJswfE2q1TZHEYA6MKjAQpI9zjMEjcpZuSp4LkNSNg1uRhZvVRWrEpxuOKM uV9YwFP4z6M5Bj4vChZwTRdfKwmPzlhH0R/0nmq0bA7fbd1U63YptSRrQvkCoUU/Gf3r 7E+Qt/rOiPQVhWZ6u2ahHBhtsn3g0IQ2pc4fpwqQzji9JZUBnJgEsI9eO7NMJM4YX46Q u4dk8EawePLKqg3hHFiJJIh96tIWz1gRpjPTw+AJC9SoDHxIucFRst1xiamwLjbuECQ7 +edJ8DEJJhm6L3oR9+glz2HxAUIplkCI+lXEHFElWgIckeZA7BUKEvqGT95gTbTY8RGm ruAQ== X-Gm-Message-State: AOAM5330E6aYVticPtZ6nnOlEq8yUvxkEU1TZonQHkDpb7X8U9G7g34I qcpoeRoCkCzdIxnTu/EscmzJKAghZH9aDdjQs28= X-Google-Smtp-Source: ABdhPJy6UcU9EPY/VYjAEgQemVBaSt0soSCFIZKzV6tZG2ud8eoWS+yD15eJvgKUJHUt7U6JGFsROSl5Tao/JZ4ZObs= X-Received: by 2002:a25:2341:: with SMTP id j62mr11299970ybj.190.1626423119127; Fri, 16 Jul 2021 01:11:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 16 Jul 2021 11:11:48 +0300 Message-ID: To: Nikita Popov Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000004529b505c73924ef" Subject: Re: [PHP-DEV] Readonly properties - immutability by default From: zsidelnik@gmail.com (Eugene Sidelnyk) --0000000000004529b505c73924ef Content-Type: text/plain; charset="UTF-8" Thanks for your response! Anyway, I probably put it wrong by saying "by default", so let me clarify myself. What I really mean is omitting the dollar sign. So everything remains the same with ordinary properties (which are mutable), and we introduce immutable (readonly) properties as another type of them. It looks like a great default: ```php public string name; ``` So, once again, it has nothing to do with backward compatibility. No one disposes the way properties are currently working. We introduce a new _type_ or _kind_ of properties - readonly. Also I see useful future scope like readonly parameters: ```php function foo(int firstParam, bool secondParam) { // no way to modify it, Error firstParam = 23 * secondParam; return firstParam * secondParam; } ``` Yes, we can implement this with another keyword (again, `readonly`), but as I see, only few people will use it because it is too complicated (really, instead of simply declaring an argument, a programmer has to write a bunch of other stuff in front of it for every single method and function). On Fri, Jul 16, 2021 at 10:06 AM Nikita Popov wrote: > On Fri, Jul 16, 2021 at 8:45 AM Eugene Sidelnyk > wrote: > >> This is replica of github PR comments: >> >> Hi there! >> Isn't it better to simplify this a bit? I mean `readonly` keyword is >> really >> long to type every time we need such property. Earlier (in php7.3) >> properties were defined only with visibility modifier. Now it is going to >> become *toooo verbose*. >> >> ```php >> class A >> { >> // 24 characters before actual property name >> readonly public string $name; >> readonly public string $another; >> >> public function __construct(string $var) >> { >> $this->name = $var; >> $this->another = $var; >> } >> } >> >> $a = new A('foo'); >> var_dump($a); >> ``` >> >> What seems for me to be better is remove `readonly` modifier at all, with >> somewhat different modification. Look at the code below. This is intended >> to work the same way as previous example. >> >> ```php >> class A >> { >> // 14 characters before actual property name >> public string name; >> public string another; >> >> public function __construct(string $var) >> { >> $this->name = $var; >> $this->another = $var; >> } >> } >> >> $a = new A('foo'); >> var_dump($a); >> ``` >> >> This is less explicit (we don't actually write `readonly` keyword), and it >> may be confusing for some programmer who is new to php. However after >> first >> attempt of modification, such layman will understand it's syntax and keep >> with it. >> >> Readonly properties are really useful for DDD, where everything is going >> to >> be immutable. It promotes best practices. However for people to use it, >> syntax should be concise and brief. >> >> @nikic , want to hear your thoughts on this. >> >> * kolardavid * 1 hour ago >> >> >> @rela589n First of all, you are coming late >> (as me before), since this RFC is already voted and implemented >> completely. >> Anyway, I find your suggestion bad. The truth is, that it is a bit more >> verbose, but I am OK with that. It might be annoying to write (word >> protected is even longer) but it is far better to read. It makes the code >> more clear. Human brain is very well "optimized" to notice words it is >> used >> to, more than symbols. This idea stays behind the fact that Delphi for >> example uses begin/end instead of { and } (even though I am kind of tired >> of it as well). Anyway, your solution of dropping $ for readonly property >> would be nightmare for everyone, not just beginners. I am sure that @nikic >> will say the same, since he seems as pedantic >> as >> I am about these things. Since all modifiers are already nice >> self-explaining word, there is no point in doing this differently for new >> modifier. It wouldn't be consistent, nor convenient. Mixed properties with >> and without $ sign would look like typo, not intention. >> >> * rela589n * 26 minutes ago >> >> The philosophy of the Functional Programming < >> http://en.wikipedia.org/wiki/Functional_programming> paradigm is strongly >> geared towards all "variables" being immutable, and "mutable" ones being >> only allowed in extreme cases (ie, for I/O. This will not look like a >> typo. >> Immutability should be provided by default. BTW, in future scope we can >> create "readonly" variables. So that once a variable is defined, no one >> can >> change its value. I oppose creating kind of `let` and `const` for this. >> >> * rela589n * 21 minutes ago >> >> > Anyway, your solution of dropping $ for readonly property would be >> nightmare for everyone, not just beginners >> >> It would be a nightmare if these values could be changed. As we can't >> rewrite `readonly` property, it looks like a constant. This concept of >> readonly properties should come along with constants not only by >> semantics, >> but also by syntax. >> >> * rela589n * 18 minutes ago >> >> > The truth is, that it is a bit more verbose, but I am OK with that. It >> might be annoying to write (word protected is even longer) but it is far >> better to read. >> >> We already have Java with it's verbose syntax. We should think what should >> be default and safe behaviour covering most cases and make such verbose >> constructions for cases not covered by default logic. >> > > We cannot make properties readonly by default, because that would be a > major backwards compatibility break. > > If you're going for brevity, something you can do is omit the visibility > specifier, as it is public by default. "readonly int $prop" works. > > Regards, > Nikita > --0000000000004529b505c73924ef--