Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112712 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 93871 invoked from network); 2 Jan 2021 19:19:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Jan 2021 19:19:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7F5641804E3 for ; Sat, 2 Jan 2021 10:54:58 -0800 (PST) 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.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 ; Sat, 2 Jan 2021 10:54:57 -0800 (PST) Received: by mail-wr1-f54.google.com with SMTP id i9so26938049wrc.4 for ; Sat, 02 Jan 2021 10:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=MEuoFIfL7anyWYI6aXwm+EREymmMoPGGeNqLyf3jT8Y=; b=PCKkTk/fibI38uiXsINgkWFZiT/cmFJ+tFjZT8plzZkUfwJ/zdKtTVxrbZbV60mWVg 8ZfHuzFJLrjssme8H8JhPlT/UaJAOz499fO0+QaZSS0fjivJz/Xc64Md9QIVAxHjU/Ep 7IPqi6nYlW7QXz1N5i1q+TGbbfJpdx76qHLBSIXOqDP4MhmQwL16+uRvUYyB1Jm6XXgP TlDBroAQRka8L7Ga+4TjvlfY9hZaeyqbmPufwZtdt9mI232frr/LqzD+BioPSTiBabhl vINMWPuTxpvrAXvmJ50s8Yt8OK5dDu38fqMIHP2cA0i8nP1U46FTHIl+ygLdCxsTWKAo ZZEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=MEuoFIfL7anyWYI6aXwm+EREymmMoPGGeNqLyf3jT8Y=; b=bp7rc5nJUowEZBxOZ6eoFghKpRQGHyUB6cxUt82hbrRuYFP5cUMOukJdv59p2YLc4C jfbPSaPNwFtRWXfXEBLa3XG24jjY7bn/2APGzbv3tW6Efp5l1AONbuIJtXyuuRt++WmJ PIU94rcD83pFXkbs5V0z7EPsDoQMV5Q+jIghkRy1jfTmC8gG193weaYnfu+HzjLXFGhS o4qULkOnwum9MbePJuZWhRFWIO5sQhVCm8vX9ek5Tug7KZiV/SV7flC7FNG2Mg6Ei17X C/P+nXSbc71aD4z1KVchNPTbDCspEj4iJb4PZ8ltgeC9Qv0SRtr6qk6M4nAiaeP3Szy8 Sucw== X-Gm-Message-State: AOAM53217gXFO29J73Uxx6cjUEiF8V1oUPxS6WEaPqfxgk4EMpG52BB3 2Ovutm+fQHHH846zktW0CreDmBwhc67ATA== X-Google-Smtp-Source: ABdhPJwFViC4O/00OCRsyv+J2DQ60qHatuYNe/7kNBx6t6GqkixmvPHrcklu9kpu73/T7Us6bDyARA== X-Received: by 2002:a5d:604a:: with SMTP id j10mr74091176wrt.290.1609613695098; Sat, 02 Jan 2021 10:54:55 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id m21sm23928314wml.13.2021.01.02.10.54.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 10:54:54 -0800 (PST) To: internals@lists.php.net References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com> <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin> <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com> <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com> <30906866-1971-8395-05a0-fd78d054bb89@gmail.com> Message-ID: Date: Sat, 2 Jan 2021 18:54:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals From: rowan.collins@gmail.com (Rowan Tommins) On 31/12/2020 14:04, Olle Härstedt wrote: > Yes, of course you can find use-cases where immutability is a better > choice, just like I can find use-cases where (constrained) mutability > is better. The point is not to replace one tool with another, but > rather adding another tool to the toolbox. The web dev discourse is > one-sided with regard to immutability, I think. Wish I had time to > implement a PR to Psalm to show something more concrete... Again, if > you only have a hammer, everything looks like a nail. :) Certainly, I didn't mean to say that immutability was always the perfect choice. I think it's popular because it's an easy hammer to borrow from the fashionable Functional Programming toolbox - you can get a lot of its advantages without much support from the language, and it genuinely fits a lot of use cases encountered in high-level programming. Where ownership concepts seem to shine is where immutability is either impossible (e.g. consuming from a network stream or an event queue) or otherwise undesirable (e.g. working with large amounts of data, or tightly optimised code). I read a bit about Uniqueness Attributes in Clean [1] and it seems they are implemented there so that the *user* can treat everything as immutable, but the *compiler* can safely mutate underlying structures. So in that implementation at least, a "mutable record" would in fact be implemented with the equivalent of "clone ... with", so that it appeared *from the outside* to return a new instance each time. It's certainly an interesting concept, particularly for the I/O case (where immutability is genuinely not an option) but how easy it would be to retro-fit to a dynamic language like PHP I'm not sure. [1] https://cloogle.org/doc/#_9 Regards, -- Rowan Tommins [IMSoP]