Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120126 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98224 invoked from network); 25 Apr 2023 16:06:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Apr 2023 16:06:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8BBE1180382 for ; Tue, 25 Apr 2023 09:06:13 -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, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 25 Apr 2023 09:06:12 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-3f192c23fffso31453125e9.3 for ; Tue, 25 Apr 2023 09:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682438771; x=1685030771; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0N8hnvhyp5LvLLFKw5Yl8+kmDcT/J1Xddu3pD0kPano=; b=HtuTn6KhrnttOd5Gs4wpZNi/pDHUcpPrwdV+h9o5K/S5LHQnl/RGytkHYx4O2zN2L9 aXhjYnnZXOhp7HWu3sSbMZ6Mp7WpxaWfqb/901MMKAokU8rvveyhXTFeFlZm+hlulpGv C/bTtaWDKUenZbIjhAo4BFlKaxCa7N1xFgqIzp0HjsCq/fFZWNcZEtH2PG5RYDy0mCV0 h1PzlYiHx93cpyX8E6ZdG9pqJcEFfFfF45Lcgx8KWO/PEp9853ri9e4ymtWeGYLZ44J8 /jQj5SXt5CVM2TsdLJS6m5xpFqtq7RNE687VT+yGSl9yuRzkmhbzB+d7VhwXsbnkf97P 4b1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682438771; x=1685030771; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0N8hnvhyp5LvLLFKw5Yl8+kmDcT/J1Xddu3pD0kPano=; b=LkxetvRGkQpM4rvvSyZpji5qY8855yleaZbE+yVug+jUEFo96xaHsxufh3gsDtu3iR 6sq6uzy8vsbuj2Aod/J6ykqunXIj5qtHbk4HIb1guin7JOqBJDkE94/tSLBeoyPquEes psrf6bHwXRQ/lSkj6pN+c4cG16m4tjgsAyYPbm8i+1G1Q4etTbMyciutkunga3bXn3Gk J/SyAsCNFjs3NC85HjnXDCzJfS61CP7XIQezkDwaIwVC+pA9i+M6D+7yBXEJus4yWR/O 4VaDm6axJsIIWNXAt/FM+5Dt9x6yfx/AwwDomlcph9/fnEMadU86SnmLfi9Rw67QgOeI U4hQ== X-Gm-Message-State: AAQBX9eaGPfFbm9PCrbRBZBPIyI/NIkq9Q93iJbPmQ+hie2pWhzKky5A FAdSF4mBUYAw5Ddg4eu58vwGQHdpB2vqWN9FysE= X-Google-Smtp-Source: AKy350aehRnk8cKIhIu9DqUR+2Ij+Xwsle9QoHxuJ4bZx0ETqmc4oUvE7JgyV+Y25oE05tgxrWXzpTrZgp3MWVvUIF0= X-Received: by 2002:adf:dc89:0:b0:2fe:c8b5:b5d5 with SMTP id r9-20020adfdc89000000b002fec8b5b5d5mr11785949wrj.2.1682438770649; Tue, 25 Apr 2023 09:06:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 25 Apr 2023 18:05:58 +0200 Message-ID: To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Cc: PHP Internals List Content-Type: multipart/alternative; boundary="00000000000047ecf505fa2b4d11" Subject: Re: [PHP-DEV] [RFC] [Discussion] Clone with From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --00000000000047ecf505fa2b4d11 Content-Type: text/plain; charset="UTF-8" Hi Mate, Quite some time after mentioning the "clone with" construct the first time > (at the end of the > https://wiki.php.net/rfc/write_once_properties#run-time_behaviour > section), > finally I managed to create a working implementation for this feature which > would make it possible to properly modify readonly properties > while simplifying how we write "wither" methods: > https://wiki.php.net/rfc/clone_with > Thanks for working on this, we definitely need improvements on the topic. Thanks also for mentioning my proposal and for the comparison analysis, that's really helpful. Quoting from the RFC: > One cannot control whether $this should really be cloned: e.g. if a property should only be modified based on certain conditions (e.g. validation), the object would potentially be cloned in vain, resulting in a performance loss. Returning a clone or the same instance depending e.g. on some validation is usually an abstraction leak. It's a leak because it allows knowing internal implementation details by comparing the identity of the resulting objects. Since the PHP community is leaning towards more strictness and better abstractions, I think this point is actually a win for my proposal: it'd naturally close the loophole in wither-based abstractions. See https://3v4l.org/02IVc#v8.2.5 if what I mean is unclear. > Sometimes one also needs access to the original instance, but doing so would only be possible via workarounds (e.g. by introducing $that or a similar construct). Here is how we would achieve this under my proposal (adapting from your example): class LinkedObject { /*...*/ public function next(): static { $clone = $this->prepareNext(); $clone->next = $this; return $clone; } private clone function prepareNext(): static { $this->number++; unset($this->next); return $this; } } As you can see, this works by *not* using the clone keyword on the public method. And this makes me realize that what you see as an advantage ("it could be made part of the interface contract") might actually be a drawback, by forcing a coupling between a contract and an implementation. That's what you mean also with your last sentence on your analyses. And that kills my proposal, RIP :) But I have another proposal I'm sending separately. Nicolas --00000000000047ecf505fa2b4d11--