Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120217 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 31875 invoked from network); 9 May 2023 09:54:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 May 2023 09:54:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D330218053F for ; Tue, 9 May 2023 02:54:29 -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=-0.7 required=5.0 tests=BAYES_05,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-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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, 9 May 2023 02:54:29 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-3077d134028so2863030f8f.3 for ; Tue, 09 May 2023 02:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683626068; x=1686218068; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1Xtm0vAMQNsnRex+pRuwMwFARRqLsayiMaoVdU3cY0c=; b=L/KLBGmrr1WqBQI4Ck6JuhL0h+jdi5aQJY94iy0gtKHPDlbvOkJt3QOZC8fFwZS6lU nF4k+ASWvCAX8ZSo8EzOhWuu2i/uPnpp10jbOnCNedihoqNvf3ul6xlJ5JVQZ97+cQ2w cS3Kdz2LX2TdOxyDIyQE6DY1mdT2lmYUntut5h95+cETACtXH0uaZRU8fAyDcw9HeV1z bFzkKPdothatUwj3rdn6NShxwXX3b8bdgbBLHvg2Qz4OaZaj+UJpmlEgLxipaT2Wr3Z9 V723x/Bg00DEOKcquR9pfFkmdWQhsA9UnlUxg98IIBweIHZatTgqzzjAtaVMSuOJtMvE WgVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683626068; x=1686218068; 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=1Xtm0vAMQNsnRex+pRuwMwFARRqLsayiMaoVdU3cY0c=; b=Hs/kYMF4KaQn9GxCMAcas1Owog/qU9YziTRYNl29nVXfzQmmpZsMAjQIVQZltiK9+7 Z7B4mLskpS9s9LmMGdVgFxQi0gF8to3yLfaS+Lid1iO64G6eUPlBQ3/JOKBKdwl/3ztV L2p5yoSyfo0wao1XGmZoTwA2wbKlo3ZPlt/7r9/UXBFvx1nAOWhmHLg5XYd0qglRKcA3 HviOaLHFaYGbnD0ryCecVOR5FiYrOvkCj6i4++0mxjzJ+yhKphQC9S0fb8pcYciE4sG2 ojJOK3vv7SmeoKmYdIvPRHenxWuXBVhkq8ZjCGmSkSFZ68D90mjqUoxPtwczCRCPloGs wO4w== X-Gm-Message-State: AC+VfDxJ+7VKSdV1o9QFRRvNU3J5jqqNgdjS8P8ij6oaelReRqde+xZu 0cYioKV/KeGn7Tw9MNzJ9Gt+bimvhwrjLZvWWN7IaIBFj9yuLg== X-Google-Smtp-Source: ACHHUZ7z3nFh74HFraiw0lk7OYNPXjBsQVXA81ZSKra9mW0Piw4A6IPCXvhB94qZRHfJ/noo4ucsFP0GzWqFJc409tg= X-Received: by 2002:adf:e4c8:0:b0:304:8888:87ad with SMTP id v8-20020adfe4c8000000b00304888887admr9707628wrm.12.1683626067810; Tue, 09 May 2023 02:54:27 -0700 (PDT) MIME-Version: 1.0 References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> In-Reply-To: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> Date: Tue, 9 May 2023 11:54:16 +0200 Message-ID: To: Larry Garfield , Ilija Tovilo Cc: php internals Content-Type: multipart/alternative; boundary="000000000000b4e09b05fb3fbd49" Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000b4e09b05fb3fbd49 Content-Type: text/plain; charset="UTF-8" Ilija Tovilo and I would like to offer another RFC for your consideration. > It's been a while in coming, and we've evolved the design quite a bit just > in the last week so if you saw an earlier draft of it in the past few > months, I would encourage you to read it over again to make sure we're all > on the same page. I'm actually pretty happy with where it ended up, even > if it's not the original design. This approach eliminates several > hard-to-implement edge cases while still providing a lot of functionality > in one package. > > https://wiki.php.net/rfc/property-hooks > Congrats for the RFC for property hooks, I like it all, including abbreviated forms, $value as default name, etc. Some notes: - does set($value) { mean set(mixed $value) { or set(TypeFromProp $value) { ? I understand it would be the latter but it might be nice to clarify (unless I missed it) - function setFullName => ucfirst is not found in the "set" version - could parent::$x::set($x) be replaced by parent::$x = $x ? Same for the get variant? Why not if not? - readonly: could this be supported by materializing them, using the storage for memoization after first access? that'd be quite powerful - I'm not sure we need ReflectionProperty::getHook('set') when we can do getHooks()['set'] ?? null - What does ReflectionMethod::getName return on a hook? And getClosure? - Should we add ReflectionProperty::IS_VIRTUAL ? - I'm a bit surprised by the possibility of adding attributes to hooks. I'm not sure I see the use case and I think this might be confusing in addition to attributes on the property itself. - For serialization: exclude them from var_export() and serialize(), which don't need virtual props to rebuild the state (you mean json_encode(), not JsonSerializable on that list), call get for var_dump/print_r when it's defined (but ignore exceptions). But (array) / get_mangled_object_vars() / get_object_vars() shouldn't call any "get". I have a bigger concern: the take on references contradicts with the intro about BC breaks: turning a materialized property into virtual one would break BC as far as refs are concerned. One idea to fix that: add a ref hook, that must return a reference. If not implemented => Error when trying to get-by-ref. This could also help solve the $foo->array[] case (including the asym-visiblity issue). Nicolas --000000000000b4e09b05fb3fbd49--