Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121771 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19525 invoked from network); 23 Nov 2023 08:09:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Nov 2023 08:09:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6455F18002F for ; Thu, 23 Nov 2023 00:09:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-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,DMARC_PASS,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 23 Nov 2023 00:09:31 -0800 (PST) Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-1efa01323b4so399941fac.3 for ; Thu, 23 Nov 2023 00:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700726967; x=1701331767; darn=lists.php.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TBPcSWbqGUu3Z2HH/dB8rRwjL8QIuVyrxQ44bF28QZg=; b=hNoDk6W8PqucMGRSRfJo8NXiRQ25sJzQVzSamTtR57hgZ6+j197zUxycTUQxYhuSNg DQhFzwMZr4iAEQrpQadg4dsIwKLWJ4HVEweVxDH1hqjZ9SVxSV0mkowtFsLlXAAKwGUl Xj4tlBddG/9q6IYt79AhsPhwIH4QQUtR2zteYVvQXP4JFGbGcClseVKlq49hYGdopZd9 blnLGvWl73qHUe62/qrWHuTW17Uz90RTonpnaaYOP3/QjIOde1uXAulveDRQ3Qd4lAX0 ylrNN/7gyqVcwEw+fFlcZ1FsUeUJOCG/WS5agzd+ddnB/15aRF894tLEjLhAzARbN/Qa ODgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700726967; x=1701331767; h=content-transfer-encoding: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=TBPcSWbqGUu3Z2HH/dB8rRwjL8QIuVyrxQ44bF28QZg=; b=hl2TvgmRkJwjJ6xNKDFjtf4KF0pElWDyBl/vco4V4ySUXAsjm5iXjsxiioS2kTmix7 iFHHNYiScvYngHzDy8ogH75GlQp4xQZqRGJ5Gj9JwN0vFivk3f72YemmjWMrmm3ZSj/8 +vvHj8OvOUkyv/pYY7a8gFVrlifREH+HaK7jYOkOXUfxcpenY/fyGSZMGm8EeIqlxKVt gI0xLgSrhR4ujCFcGO7ZzeLiNK2Z9iJQP7g+Js5Wgy+PVtbMo6uHkLOt3RKWY/+VstUW 4hUCN8RLHaJOcI7XahoIlK35/ElqyArw4eAcw69ol8p4lBD9atq2KPZ7VKR9Qx0z2ITU 886Q== X-Gm-Message-State: AOJu0YyorX6o09eQ4B4rDZfSq4nJeD0pV0DVcx5wQkLDdqf/aEjphi5N RV7Gz0ZvPstx8Unht7PHMZ255aOZdkN7urvPaGM= X-Google-Smtp-Source: AGHT+IE7ZJHpEzrx21VQ0qhO3NayDYQ5vx0Z7Uyg+x0uycwNWntzstloM+37KC85UxdQULUs977MEx9dbI1LyqjTBOY= X-Received: by 2002:a05:6870:3d90:b0:1ef:b0d5:de4f with SMTP id lm16-20020a0568703d9000b001efb0d5de4fmr6559854oab.23.1700726966800; Thu, 23 Nov 2023 00:09:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 23 Nov 2023 09:09:15 +0100 Message-ID: To: Rowan Tommins Cc: PHP Internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties From: landers.robert@gmail.com (Robert Landers) On Thu, Nov 23, 2023 at 8:56=E2=80=AFAM Rowan Tommins wrote: > > On 23 November 2023 01:37:06 GMT, Claude Pache w= rote: > >What you describe in the last sentence is what was initially designed an= d implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 (sec= tion Overloaded Properties). > > > >However, it was later changed to the current semantics (unset() needed i= n order to trigger __get()) in https://github.com/php/php-src/pull/4974 > > > Good find. So not only is it not specified this way in the RFC, it actual= ly made it into a live release, then someone complained and we rushed out a= more complicated version "to avoid WTF". That's really unfortunate. > > I'm not at all convinced by the argument in the linked bug report - wheth= er you get an error or an unexpected call to __get, the solution is to assi= gn a valid value to the property. And making the behaviour different after = unset() just hides the user's problem, which is that they didn't expect to = *ever* have a call to __get for that property. > > But I guess I'm 4 years too late to make that case. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Heh > But I guess I'm 4 years too late to make that case. 4 years ago, I was using this behavior to write proxies that actually called things over the network instead of the properties. I didn't file that bug, but I probably would have filed something similar. Nowadays, those proxies are dead as we long since generated code based on interfaces (so they'll pass PHP type checks). I venture once we have property hooks (assuming that is still a thing coming along), this behavior can be removed completely as you can just use property hooks instead of unset to call __get. I'm actually quite excited about property hooks and hope they pass. Personally, I haven't used this behavior since 7.4-ish, and I'd be surprised to see it relied on in modern PHP: code generation is too easy these days. Robert Landers Software Engineer Utrecht NL