Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115872 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68755 invoked from network); 27 Aug 2021 00:45:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Aug 2021 00:45:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4D3511804B3 for ; Thu, 26 Aug 2021 18:19:59 -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=3.2 required=5.0 tests=BAYES_40, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL 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-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (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 ; Thu, 26 Aug 2021 18:19:58 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id i9so10848148lfg.10 for ; Thu, 26 Aug 2021 18:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8RXV0rJIBqxj/EIrsVK0j4dCYGvYCgp4y1URHYaxFNA=; b=LUuyIMieO2/cx7v7SETpwCdn5B5m5zyItC6/kTY6/xZs61/eisRxwDTOyQrjCOevNX +3tyr1nCwyg3zVXoFmcBrEUtBUvrOY/g/9uzRo0sg+VUKVD5P8Qe0VoQRZDFJ/pPYnMo e42Ln5MZ4Jpv9ziC7KSKLdBnJr1bAgdHLNgT6SA2C8ubmMOHjYwIaaarQ35QZah+3RUF YtSYN4wFwmj46QtbICRvgF1PQRKmv/P2/AGj9wVTvAiKGJE6IneIUS8M4dpvJK7NQ122 ziHzS39Lv7VNbFkOnRajPA0W5Q9a6whD2KzwUXWlqzufg4zc+wudKs43y8YvQ98zv7Eh te9A== X-Gm-Message-State: AOAM532isvb8PVp6mkxwlLa5zqCD+CqPXceDkqYTMso8LQMpz0kQjpve fdyTJ1gXIeT/WshzxdL7TltyKKpTdpTa7kVFzmKrf1IYXawNLw== X-Google-Smtp-Source: ABdhPJwAgs9yIWVW6o0Yz6nWk830UPoJL4HhJfKinhVxeX7SrpUehY163TqLG1UpFtB90hNggN/OcupkY1HUKtSWHpU= X-Received: by 2002:a05:6512:114a:: with SMTP id m10mr4717405lfg.397.1630027194732; Thu, 26 Aug 2021 18:19:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 26 Aug 2021 20:19:43 -0500 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000eaa8a605ca80470e" Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties From: pollita@php.net (Sara Golemon) --000000000000eaa8a605ca80470e Content-Type: text/plain; charset="UTF-8" On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov wrote: > > The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic properties, > but otherwise keep dynamic properties as a fully supported part of the core language. > That's how I initially read your RFC, what I'm hearing here is that your quite explicit goal is: > 2. Remove support for dynamic properties entirely. The core language only has > declared properties and __get/__set, and nothing else. stdClass is just a very > efficient implementation of __get/__set. > If that's your position, then the `extends stdClass` approach makes sense, because the dynamic properties HashTable can live in the object's extra data offset block and the get_prop/set_prop implementations in stdClass' handlers are the *only* things which know about dynamic properties. That represents a significant advantage to the engine for the "happy path" of declared properties only. Every (non-dynamic) object is a word (8 bytes) leaner, and the branch points for dynamic property access are limited to the only place they can be used, and where the typical result is positive. Starting from that argument, your RFC begins to look more compelling. I was definitely not starting there on an initial read. I do still have reservations about enforcing stdClass as a root for any class which wants to use dynamic properties. It's messy, but... to paraphrase what you said about going with an attribute approach... yeah, someone could make every current root class in their application explicitly inherit from stdClass without any ill effects in PHP < 8.2, with only the exception of external libraries being a problem. So that's the spectrum: - Opt-in to strict behavior: No BC impact, least benefit to the ecosystem or the engine - Attribute/Interface opt-out (goal#1): Moderate BC impact, ecosystem benefits well, engine benefits a little, but not much. - Extend stdClass opt-out (goal#2): Highest BC impact, ecosystem and engine benefit most. Goal#2 is bold. Possibly not-too-bold, but it's not clear to me where dynamic props are being used today and how many of those places can't "just extend stdClass" for one reason or another. Goal#1 might be a stepping stone along the way to Goal#2, as it will give us something clear to scan for across major frameworks at the very least, but that is going to push us from removal in 9.0 all the way out to removal in 10.0. If you're keeping track, that's gonna be circa 2030 give or take a year or two. That might be dangling the carrot out a little too far... The purist in me wants to be bold. It also wants some hard data on existing usages. A simple grep isn't going to cut it this time. We're going to need to run some static analyzers on some frameworks and libraries. Who's got it in them to do the research? -Sara --000000000000eaa8a605ca80470e--