Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125962 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 70E841A00BD for ; Fri, 15 Nov 2024 07:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1731656693; bh=zA6yjk7d9fG+cWaks21PRKq/IgPsvxrfcc12DgIc0QQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=i5UBPkzO4Agrc4GfYmB86d55HIKER9RV/mgfsm8VvlStyriSfP0g9VOu8C8FtS6hr L8EKqInjUKlJYkpemWsZ+/tgIyxgDZhe5ouOFLtUdoYQQVkBy6VE5xBcwkub8OxmXJ 5dRP5gxiplZKXjCvv23BN+07gwf1T2O+71x4fBcg1lMtOsPjkpIRcSQ5Oe3jpfj5R/ T4UqD/fJclPmkjVIHbeZtl3W3L6ESkKBXDouz6nOtLgr61SUawlbn4/XebxoQwBaKz NNlgcvTVTHbfMR5K+OftVrmn4mTweoIH/XFVBORev8ZH5e9I8SfKXY+lJl8/9u9UmA W0VeI71vOdIlg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D0A2E1801E4 for ; Fri, 15 Nov 2024 07:44:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=BAYES_50,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLY, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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 ; Fri, 15 Nov 2024 07:44:48 +0000 (UTC) Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-856e4380e34so164829241.2 for ; Thu, 14 Nov 2024 23:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731656531; x=1732261331; 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=qVZZ/v1Ex+bnYtCdh1ipAbCJYY1gxdR5FnosFnGekfo=; b=lo/N1L5NJSkzM9sgSV5X1hIM7OjTP3uikjZbSBLdtVhqOFsz31X5I0lQi2fN+lAcRz lnrAyIREwJKfyRdUH1+HIiZV4muGxlb8Jdmul5HmXaznds4PBmse4KSQcGP81yywyBIS VGf/hDVo7WV0mR34ikapKIY23KleEgXq5k6Mv+Oh9qKUlr8ISMfeok6R57Kg6VaEVDgR ZWmiIz8BaSuxRzM9O/F4Vxg0VyaQZ820rmP8FVdciKjCpdjqwf4tzYxwSG04sqes+de+ XbL5goqLeR4t4TK4xrtaoSon/WgURRnKBPLWQpqNyd9Kp+ZSjyfq/Rv172L2Jro/ue3d YTsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731656531; x=1732261331; 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=qVZZ/v1Ex+bnYtCdh1ipAbCJYY1gxdR5FnosFnGekfo=; b=j+3iNVTDTWtFeNC0xBRYzrhx0aesX8uVnoK41PlA9aHs24ip/da9hUZXLA59YY5/hX rWZ2+Ju78//kJjaKfJT0LKyiswQEkU2BVSwlPkfqQeorjBijgZgEgOot6OwTuOJTuV+V cbUmwhnLgmsICMwWhfl5LLETn6zK1gwpz0+lG/qFIHrZJuCb8FwvgaaQCWWNo8lwd9pk sw1gvs71xoa1CJJhPLaylapgC0Ner9GjxsNMZS4SQMOEBgfd1NTPztXtr7YUupm2M+2d mTYV5ztd9nmm5O8ew2ulfjnAJ4Ip9l4u5SaU3olt4IOCLbFu+veDyD+uYCH7ZnresMP9 6E5Q== X-Forwarded-Encrypted: i=1; AJvYcCXx6YzLMHLfNstdqBHwCpRKXPjYDa9TX2a2MZvzFs0ONDv8CbkuwErtRS8kd5CIYZX+MuGpIk5YNrU=@lists.php.net X-Gm-Message-State: AOJu0YzbuO/WeJe/MMhJlx2sam5kIll40fwS5cBiBDbtvt0m5LsEqdPs 6ChPK/h1dYpwIYEhM4+igvOBXSz6XgbXadsoiSYFE3dIziLRd4wulgxJ53OtRma5SyWiUVB22Kk WMbF1tEptb40RnqtFQ52x8387uq8= X-Google-Smtp-Source: AGHT+IEDhkL4xqkMlNOJYD7/nh3KE8JeBp0bLKis5WmHxB0aBu+dL+RgvMRDKDFsonwPD3Xm4qYyekLMnRzmhahU9aU= X-Received: by 2002:a05:6102:e0a:b0:4ad:641f:e63a with SMTP id ada2fe7eead31-4ad641fe6fdmr1441277137.2.1731656531087; Thu, 14 Nov 2024 23:42:11 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <3dcc5393-6ce7-465c-abe6-ecb687b0f369@app.fastmail.com> In-Reply-To: Date: Fri, 15 Nov 2024 12:42:00 +0500 Message-ID: Subject: Re: [PHP-DEV] [Discussion] Make objects unpackable by default To: "Gina P. Banyard" Cc: Larry Garfield , php internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: ilyaorlov124@gmail.com (MrMeshok) I do know about get_object_vars, but for me foreach ($object as $prop) {} looks nicer and a little bit faster (probably because there are no function calls). Also it's more flexible because in future you can implement an Iterator on class and alter iteration behavior. But after reading through https://externals.io/message/103718 and https://github.com/phpstan/phpstan/issues/1060 I can see how this behavior can lead to bugs if the developer didn't intend the object to be iterated. So a better approach would be to add getIterator to all my DTOs ```php public function getIterator(): Traversable { return new ArrayIterator($this); } ``` But ArrayIterator is a lot slower than simple object iteration (2.4 times slower with only public properties in the object and 1.5 times slower with some private/protected properties). It would be nice if there was some lightweight ObjectIterarotor designed to work with object properties. Also some note in docs to discourage usage of object iteration would be good https://www.php.net/manual/en/language.oop5.iterations.php =D0=BF=D1=82, 15 =D0=BD=D0=BE=D1=8F=D0=B1. 2024=E2=80=AF=D0=B3. =D0=B2 02:3= 0, Gina P. Banyard : > > On Thursday, 14 November 2024 at 17:24, Larry Garfield wrote: > > > On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote: > > > > > Am 14.11.2024 um 10:59 schrieb Marco Pivetta ocramius@gmail.com: > > > > > > > On Thu, 14 Nov 2024, 11:29 MrMeshok, ilyaorlov124@gmail.com wrote: > > > > > > > > > Hello, Internals! > > > > > > > > > > As you know if you try to unpack a regular object (`...$object`) = you will get an error: Only arrays and Traversables can be unpacked. > > > > > I don't really see a reason for this restriction, because foreach= on objects works perfectly fine, so I made a feature request on GitHub to = change this behavior (https://github.com/php/php-src/issues/16038) and was = advised to see opinions on this here. > > > > > So, what do you think? And does this change require RFC? > > > > > > > > TBH, foreach on objects is already quite an abomination in itself = =F0=9F=98=AC > > > > > > It is a bit less weird if you use value objects or json data in objec= t form. > > > I would be careful to judge how other people use the language, just s= aying ;-) > > > > > > - Chris > > > > > > Judging how one should use a language is a core component of language d= esign. > > > > I'm with Marco on this one, and I'd be more than happy to get rid of fo= reach($object), too. It's way, way more complicated a topic than you think. > > > > How does visibility play into it? > > Should hooks be invoked or no? > > Do references play into anything? > > > > Those are some of the questions we had to deal with for hooks and forea= ch(). It's non-trivial. You'd need to address all the same edgy issues here= , too. > > > > And that's assuming it's even a good idea, which I don't think it is. I= f you are using a value object to define unordered arguments, just pass the= value object itself. If the receiving function can't handle that, then it = is simple enough that you don't need a value object. If that's not the case= , then your code design is bad and the language should not try to paper ove= r that for you. Either simplify the function or adapt it to use a value obj= ect directly. (With union types you can even do so in a BC fashion much of = the time.) > > Agreed, this bites us constantly when needing to reason about what an "ob= ject" is in PHP. > Similar to array it mixes the concept of a struct, with that of a referen= ce value, and "overloading" various behaviours (e.g. iterators and ArrayAcc= ess). > It is *extremely* simple to go from foreach ($object as $prop) {} to fore= arch(get_object_vars($object) as $prop) {} > and mandating this would resolve a lot of complexity, be that from the pe= rspective of what is "possible" or not to do, and from an engine PoV. > > > Best regards, > > Gina P. Banyard