Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115431 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8832 invoked from network); 16 Jul 2021 06:42:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jul 2021 06:42:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E7BD0180089 for ; Fri, 16 Jul 2021 00:06:37 -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-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 00:06:37 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id s18so12712170ljg.7 for ; Fri, 16 Jul 2021 00:06:37 -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=oXqStFyqIqkYswrQRmmJzBWM/7BN5B/sWNTqlDJXZuA=; b=nSw5UnKz/EcOF+52J1e30ihC5LPEpILVTZzpwJl0BWz/H19lIgmwsaKTYQr8yI6w+Z jq/2S6iujVQZkijOVNlL49kWMjFUUijHgEDNGL8u1GqyujOAI95sbK2/gwV8IWMMc7BG fVI6LcG3/CxXSZGdOsEd4S1ccVusjeFVsweUMM9kK1VfILbDvNdpX/Hu4gLoZemQWwvb xECdGOg7qwCzC484xYXaVhFOCRM7uzOeuEf5nX7sgFI30uka3VpDJ8FZKYelPiIJYnCh eB2Er/bwWQe9y3kiQoLmLzrziosTa1OWDE+Us+zj+SY+Wg9fp7IVw7vieBrRMXF6fLRy sakA== 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=oXqStFyqIqkYswrQRmmJzBWM/7BN5B/sWNTqlDJXZuA=; b=nmvgjd3aSfw9r2OG3asOMPekZnYYxSvgY3Szqg4fdP4FpssEXjxPwx3xXBUf5po1ly eCMCqhRifvLcgsrEA/KeCCmxUNnvtxIxQ1jIa3T6W1Lf5m4r1urUcp6R1JO0iYpxbb0O 5XhLEof+K4bV9PGc1eE1B3YJP9+O7nSeNGntBgvxye84j09xC0Ayj7fhShw0Zk37s1Vu WKB4L9SzqT/OwkhaMrIQfUHMKet60JYJ/wYr/Neqit8F867OTMiqpC0O6UE1nnGaFD/m kFyFaQKY+MSEgvAkMMsTyO7lR+Fel2HfqS3DuplqcF1j2ZTXt23bvC4v3VNfIlBO0Ktz oVrA== X-Gm-Message-State: AOAM533bJDEkEUTZTzJDkYZ8eNklNaD5ZittRtw8LOrghYFzsF/ItYEP 79fznAyvyV12ceO0GCYdbh5dNxgkrxcZLqmZWME= X-Google-Smtp-Source: ABdhPJwBM47bWlNlbKmeNbrd3Ck3z19QJjfdRfe08JkR/btB1JQ8NbuxZS1ycYNJVbCuhiyspcZC4b+zwUalu7uc7l0= X-Received: by 2002:a2e:bc0c:: with SMTP id b12mr7806761ljf.244.1626419194528; Fri, 16 Jul 2021 00:06:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 16 Jul 2021 09:06:18 +0200 Message-ID: To: Eugene Sidelnyk Cc: PHP Internals Content-Type: multipart/alternative; boundary="00000000000058891905c7383a7e" Subject: Re: [PHP-DEV] Readonly properties - immutability by default From: nikita.ppv@gmail.com (Nikita Popov) --00000000000058891905c7383a7e Content-Type: text/plain; charset="UTF-8" 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 --00000000000058891905c7383a7e--