Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115812 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 81707 invoked from network); 25 Aug 2021 13:26:49 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Aug 2021 13:26:49 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1569B1804CF for ; Wed, 25 Aug 2021 07:01:04 -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 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-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (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 ; Wed, 25 Aug 2021 07:01:03 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id f2so43868149ljn.1 for ; Wed, 25 Aug 2021 07:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bebFen61SJOH5Nm9ucEAPwRiz2AvfO2KirvMUqIREuc=; b=OHuXtxzpsq2P1GMPvi6QjqUojDrDo4DylDRl4x/62CywwPJx8RzRgmTC8s4ma59Dom ARbuNebxToti1MKTIsS1sa52aiY4jGN5PEzkrPn9HoLb4J4zXGxwLvKcIZIvTQ4O3bnv iXyXRvO+wlUel5lwIBVJvi5vV9LnYOxyAEq7T7yF99qDGH6c6hFK9uBqAPzehf7rN3lr FA6yfvo8C427PqN5qlXsovSIlhc7hNLW2f6oO8lI5g+32dnpSgOF5FKp+wTmL65Dd1bx JCTTcnRP1qJZGvVDSx2cnkkg8hiXvBb4z1wHEHeJXTGpQStt+Ii1AGz8/YyVCk+yArqW MfHQ== 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=bebFen61SJOH5Nm9ucEAPwRiz2AvfO2KirvMUqIREuc=; b=Q9cNxXnMjkaHyJ38oC7sXqDbnIuwtwt8HICsEp2jW/DJCdcNLQGfPYzhD3iwPU6ztv 96SEE0gR9IXHe8Yk/NPzWqj9fNr3pJxWoHm1yrJv+L3jZv3SC+aO6hXT6j0JMyuonDaO x00Q+QIIzB4kGnzN5hDKWq1mTPubUNZ68ThpM0lgr5B0CODo7oWJHJROv4gfNN5eFwF6 IFbFqaRhfJDMkSOHhvV0lsxYD9YnrapwL7/TJcW3UjArD1b5KRaTXi4gYKTKmB3v4SaW eCEmMP3Z4ikp8fCPCE/vyc6AgjH6iUpxXW9lNE8KNQ16RoPngiSZ6TYIqUNS43NajZyt M5pg== X-Gm-Message-State: AOAM533kAkg+pUkkk6YrZyJiLLGm0leNuqfCRcsvikyKEdAIxQkjpxUP CnSmGPYvqEazZE27MH3ewQEXkS9GJ8J3U3ztvk0= X-Google-Smtp-Source: ABdhPJzLuQIrsL6BQ4owyMQK23RCn2jvxXXXk6NrsrlfztS9zJ9sM1ggrosk17Jc34xY/FT3gTKucaX9Ut9gKtTH6xk= X-Received: by 2002:a2e:b55b:: with SMTP id a27mr37964552ljn.353.1629900060625; Wed, 25 Aug 2021 07:01:00 -0700 (PDT) MIME-Version: 1.0 References: <763725c0-870b-e8c4-054b-1ea0481ef877@gmail.com> In-Reply-To: <763725c0-870b-e8c4-054b-1ea0481ef877@gmail.com> Date: Wed, 25 Aug 2021 16:00:44 +0200 Message-ID: To: Rowan Tommins Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000022113d05ca62ae87" Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties From: nikita.ppv@gmail.com (Nikita Popov) --00000000000022113d05ca62ae87 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 25, 2021 at 3:51 PM Rowan Tommins wrote: > On 25/08/2021 13:45, Nikita Popov wrote: > > > We obviously need to keep support for dynamic properties on stdClass, > > and if we do so, I would expect that to apply to subclasses as well. > > Does that actually follow, though? Right now, there is no advantage to > extending stdClass, so no reason to expect existing code to do so, and > no reason for people doing so to expect it to affect behaviour. > Isn't this a direct consequence of LSP? We can't just drop behavior when extending. Only way for this not to follow would be if we disallowed extending from stdClass entirely, which we presumably don't want to do. > Second, I consider "extends stdClass" to be something of a last-ditch > > option. If you encounter a dynamic property deprecation warning, you > > should generally resolve it in some other way, and only fall back to > > "extends stdClass" as the final option. > > > That's a reasonable argument in terms of the multiple inheritance case. > > My concern about the name remains though: people already do get confused > by the name "stdClass", because it's not in any way "standard", and > tells you nothing about what it does. > > Reading "class Foo extends stdClass" gives the reader no clues what > magic behaviour is being inherited; "class Foo extends DynamicObject" > would be much more clear. Similarly, "$foo = new DynamicObject; > $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" > Yes, I can see the argument for aliasing stdClass to something more meaningful, even independently of this RFC. I'm not sure it will have a big impact for this use-case though, because using the new name would require polyfilling it, so I'd expect people would stick to the old name in the foreseeable future... Regards, Nikita --00000000000022113d05ca62ae87--