Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109280 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 514 invoked from network); 25 Mar 2020 00:12:16 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Mar 2020 00:12:16 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E90E41804C6 for ; Tue, 24 Mar 2020 15:36:46 -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=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 116.202.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (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 ; Tue, 24 Mar 2020 15:36:45 -0700 (PDT) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 273FA60ED7; Tue, 24 Mar 2020 22:36:44 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1585089403; bh=iTakH6Iv9sh7mpy/bfucLxCUAs/Q9Sdjb5abuECpcZw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gW17numnZYLqlsNTg6ScwhurJGbGMF2q1PvpppJUqKA21f8OmAkfgMmn0SzX9uBQv dymfThndUMK8O1J0TAbDBKGd0fU2nEGv3beuaWk1h1etC/DNCb/j4SNVRIteaDJ+19 XNG1tZ/KGELCzaj+oMpzajPLJLgusII9TcEs1gn4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1585089404; bh=iTakH6Iv9sh7mpy/bfucLxCUAs/Q9Sdjb5abuECpcZw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XclgRv1MmwVqTzscr+HoGqVRAQaEQjdKRYwOnUktuxQdJoKLz6Ifix3sWTkvwLO4y JsHEUZfD9y/K4niQ44a2UISiw3MdDGAFTJnI1jZd1KaarGycb7i8jpFjGFzs3CtvQb CzmgXoTxihQHMYpN1zqhNqMpoIfbSDU3UJDAuhFY= To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , =?UTF-8?Q?Micha=c5=82_Brzuchalski?= Cc: Larry Garfield , php internals References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com> <0af67f9d-ce2a-476f-abad-385080ce14e8@www.fastmail.com> Autocrypt: addr=d.h.j.takken@freedom.nl; keydata= xjMEXimHTRYJKwYBBAHaRw8BAQdAzvRUI24yOGvteVk9N6VKIt425fNgg0P1rvD2WQLGP+fN JERpayBUYWtrZW4gPGQuaC5qLnRha2tlbkBmcmVlZG9tLm5sPsKtBBMWCAA+FiEEvtrj9qG2 TA2YmjvLhef0X6cSlpAFAl4ph00CGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA IQkQhef0X6cSlpAWIQS+2uP2obZMDZiaO8uF5/RfpxKWkPywAQChh9Z1jSvitkT3sIipwMlk dnUlYY5Ue3lHBBhF6pQUOwD/XtEz/fsjvqE/GpjJhXpxNodwKjLhaUiFe9qRwwH/5QXOOARe KYdNEgorBgEEAZdVAQUBAQdAMNSCUI0PnOjjrFKZDAFRQzKLVDCINuFNgsXh0snmlUwDAQgH wpUEGBYIACYWIQS+2uP2obZMDZiaO8uF5/RfpxKWkAUCXimHTQIbDAUJCWYBgAAhCRCF5/Rf pxKWkBYhBL7a4/ahtkwNmJo7y4Xn9F+nEpaQEYUA/2mZ3uEN0JTRUZbxHGBMB4IhQw0cdIML FpFrTycqUCXCAQD5rWXomBWVD/DRHk7O3KjNsek9F1DEZgGeZ5pPmNF/Dg== Message-ID: Date: Tue, 24 Mar 2020 23:36:39 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.2 at c03mi01 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis From: d.h.j.takken@freedom.nl (Dik Takken) On 24-03-2020 10:21, Máté Kocsis wrote: > Hi Larry, > > In my opinion, one of the core assets of PHP is that it contains relatively > few syntactic sugar compared > to some other languages, e.g. C#. Maybe it's just me, but I believe it > makes the code written in PHP > easier to read. And I think this is what we should optimize for. Not for > saving a few lines of code, > but for making the code easier to read and understand. It's not just you. :) I fully agree with you here. PHP has a straight, down-to-earth character with very little magic going on. This is what makes the code easy to understand and debug. I just would not use the term 'syntactic sugar' in this context. To me, syntactic sugar has a positive connotation: A nicer way to express the same thing that is easier to read. Magic is making things happen in non-obvious ways that are easily missed when looking at the code. Magic can look really attractive, until something does not work as expected and you fail to see why. Python code tends to have tons of it. The point where sugar ends and magic begins is a matter of taste. To me, constructor promotion tends slightly towards magic. But then, anyone can choose to use the feature or not. > To be honest, my impression is that most of the problems you list (e.g. > verbose constructor, bean problem, > or even property accessors) mainly boil down to the verbosity of PHP (or > the "visual debt" problem > how some people calls it). As I wrote in the first paragraph, I don't think > it's a bad thing. Reducing verbosity is not the problem. Introducing magic is. While property accessors are magic, they are a form of magic that I would be willing to accept, for the following reasons. A nice feature of accessors is that they allow swapping a traditional public class property for a property accessor without changing API. Such a feature currently has little value, because public properties are not commonly used because they cannot be marked as read-only yet. Once public class properties can be marked read-only I would be comfortable exposing them directly, without writing any getters and setters for them. The only thing that would still worry me is: What if I need to add some form of access logic later on? Property accessors allow me to do this without introducing a BC break. So yes, property accessors are magic. However, in combination with read-only properties they would allow for dropping tons of getter methods and directly expose properties in stead. They allow this because they are the 'safety net' which makes me comfortable doing it. We get more PHP and less Java. This probably means that I will occasionally have to actually use property accessors at some point and introduce a bit of magic. Then, it still isn't the worst possible magic. Accessors are explicitly declared on the class, an editor could easily show me that accessing a particular property calls a method and show me the code. It's not ideal but it's not that bad either. > But I don't understand why is would be a good thing to have two types of > methods? How should we decide if we > should use normal methods or property accessors? I think the current I would prefer to only use accessors to add logic to property access without introducing a BC break. A successor to using __get() and __set(). For access logic that is obviously non-trivial from the start I would probably continue to use regular getter and setter methods. > I still don't think that property accessors would solve the main use-case > of "write-once" properties. Indeed. For that purpose I would prefer a keyword for marking a public property as read-only. Regards, Dik Takken