Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112114 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 83706 invoked from network); 26 Oct 2020 08:44:33 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 26 Oct 2020 08:44:33 -0000 To: internals@lists.php.net References: <5f92f1e0.1c69fb81.a800f.cbe1SMTPIN_ADDED_MISSING@mx.google.com> <2A808AB8-7179-41F6-88F4-A19C8F7FA171@newclarity.net> <02DD5C20-522B-46C7-B5EE-BC61E2EC4C6F@gmail.com> Date: Mon, 26 Oct 2020 10:02:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <02DD5C20-522B-46C7-B5EE-BC61E2EC4C6F@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Posted-By: 79.207.25.186 Subject: Re: [PHP-DEV] Is there any interest for object constructor shorthand *just forstdClass* From: php@philiagus.de (Andreas Bittner) Message-ID: >>> I don't follow; is the resulting JSON different if you cast to >> object, or is there some other reason you prefer an object over using >> an associative array directly? >> >> The by-reference semantics of objects vs arrays in PHP. > > > *shrug* If you want things to be mutable between functions, stick an & in front of them; if you want copy-on-write performance, leave it to the engine. That doesn't seem to have anything to do with JSON or API as a use case. Agreed. My original point might have been badly phrased and was only made to reinforce that \stdClass is currently needed and widely used as no other structure exists that offers dynamic property names while still being forcefully JSON encoded as a JSON object. We could replace this with another class. Maybe a real map implementation. But without the replacement being present \stdClass should be removed. With regards to the JSON looking different when casting to object: ``` json_encode([1,2,3]); // result: [1,2,3] json_encode((object)[1,2,3]); // result: {"0":1,"1":2,"2":3} json_encode([]); // result: [] json_encode((object)[]); // result: {} json_encode(['key' => 'value']); // result: {"key":"value"} json_encode((object)['key' => 'value']); // result: {"key":"value"} ``` While it only applies to empty and sequential arrays I think it best to hand the desired structure (object or array) from PHP to json_encode and not leave it to interpretation. I usually provide json_encode with an object where I want to have an object result, even if I know that the source is already an array with string keys. >> That pattern can have a non-insignificant performance penalty when >> dealing with a large number of objects, a use-case that is not >> infrequent when processing JSON, especially responses returned via an >> HTTP API. > > > That gives us all the more reason to look for efficient ways of populating anonymous class instances, then. (And, indeed, populating actual named classes, if such a penalty applies to them too.) I am not familiar with internals, but I can't imagine that omitting `new` could have any performance impact at all, as long as the constructor would still be called for non \stdClass objects. For \stdClass objects it might be possible to find a performant way of handling `new \stdClass(...)` with close to (if not the same) performance as a proposed `{prop: 'value'}`. I'm not clear on the advantages of the new syntax from a language perspective. Would `\Bar{a: $a, b: $b}` still call the constructor? If yes, it would be a cosmetic change only with negligible (if any) performance impact compared to `new \Bar` with named parameters. If no and the arguments would be written directly to the public properties of the object, I would consider it a bad pattern, given that internals about the setup of the valid object might be unclear to the outside user. What if the class has additional private properties? The control over valid construction of an object must be located in the class defining the object imho. > I see stdClass as a badly named and no longer necessary kludge, and would rather see features that help replace it than features that rely on it. Do we already have a comprehensive list of features and use cases for \stdClass? If not I would offer to compile one to the best of my knowledge for a separate discussion on how to replace \stdClass if possible and needed.