Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115442 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60024 invoked from network); 16 Jul 2021 15:49:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jul 2021 15:49:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8C9CF1804D0 for ; Fri, 16 Jul 2021 09:14:08 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 09:14:07 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9D0CB3200922 for ; Fri, 16 Jul 2021 12:14:05 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Fri, 16 Jul 2021 12:14:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RuxWc4 NGywQNTDknVZxN0kY7sbrAWc5iOMWJtxD47mE=; b=NPDYNGKkKNSxtYn+mCxyxE HO9X1kyjR3CayggjJUH+vcyZvST1pUJiyYd7a2ynk7MqOhIBWC5dPU84SvKsw+1b QImGjc4U59W/iOJhudpNiTNx84clJdgbm9cz+LXUK2YxnBenBt7xXq7r6U/hNaky w2yzvAKdMO9kSHsbvwGz6n8ym4MqMYhtHsvRuI81Pbk6zSQHYRZy74C0y5RuPCnr gUbJIswr/54GGubaByvjWtzYR1Aa6cKjfnJbNJmHAnrfVu+JVgCnazR/1vMrPLwH gFsFajnDHUpIU8WtJftBoUmqcFdVO9timaACknIP1o3lnUPhEDrb57CB9SwBCvyA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepgeelgfekudeivddvteffueejffdthfejieevhefgffek udevkedtvdelvddvffefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD1FEAC092E; Fri, 16 Jul 2021 12:14:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-ID: In-Reply-To: References: Date: Fri, 16 Jul 2021 11:13:44 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Readonly properties - immutability by default From: larry@garfieldtech.com ("Larry Garfield") On Fri, Jul 16, 2021, at 6:48 AM, Eugene Sidelnyk wrote: > @Nikita Popov I'm not sure what you mean by saying > this: > > > We're always explicit at the declaration site, it's const FOO, function > foo, class Foo etc > > > Regarding your message > > > Here mutability is decided by single $ character in the declaration, > which doesn't have a particular obvious connection to mutability. > > Yes, that is not really obvious about property mutability when we look at > the code. > I think it is probably better to rephrase it into something like: New way > of properties definition without dollar sign. Not only do we remove dollar > sign, but these properties can not be reassigned. > > Looking from this perspective we are trying to improve code quality and > developer experience. Using immutability (as well as type-hints with strict > typing) makes code less error prone. This should be promoted in the PHP > community. > What I want to say is: good things should be easily done, easier than > things which are more error prone. > > Again, about explicitness and obviousness. > Imagine (just for a second) that all existing properties are immutable by > default. Then someone submits RFC to add mutability for them. It is > accepted to add a new keyword like this: > > ```php > mutable public string $bar; > ``` > > Hence I mean: currently we have one default option (mutable properties) > from 2 options. Why do we need to create such a long keyword just to use > readonly properties (if immutability is better than mutability)? > > Regards, Eugene A) Please don't top post. This is a bottom-post-centric list. B) As others have said, if we were designing the language today we would do it very differently. I'd likely push for following Rust's example of immutable by default, super strong typing, and a `mut` keyword to poke holes in the immutability where necessary. However, we have ample existing code that cannot be broken, so that limits what we can do. That means adding a readonly/immutable/whatever flag is the only real option, even if it is annoyingly verbose. I can see the logic behind "initialize at runtime constants" which is what you're describing, as an alternative. However, that breaks a ton of existing patterns. 1) Variables in PHP always begin with $. For all time, Always. 2) Objects do not have constants. Classes have constants. Introducing object-level constants is potentially confusing. 3) Constants shouldn't be set even once. Properties can be, but properties have $ on them. 3) What would reflection do with these object constants? Are they still properties according to reflection, or are they something else? Can I enumerate mutable properties and constant properties together or separately? This gets complicated fast. I agree with the point that the verbosity of `readonly` is potentially annoying, but we haven't seen it in practice yet. If it ends up being a problem, then as someone else suggested a more likely solution is a `readonly` flag on the class, possibly with a `mut` keyword on the property to opt it back out, or something like that. Not ideal, but probably the best we could do. Having very subtly different syntax for a very significant behavioral difference in properties seems like a landmine waiting to happen that would only confuse people. --Larry Garfield