Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123679 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 2D45E1A009C for ; Wed, 19 Jun 2024 15:30:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1718811073; bh=VoU/fnL4ANpyTNGWUty/Mpzf3uhNNm+qb5sOqABpqTM=; h=In-Reply-To:References:Date:From:To:Subject:From; b=IL6stceTcYMCo2i2ztcieB5ZxIA0c9FVC/xvi3bELsKch4EL3px8VRkSKaRHSqoS3 diNWauur5vJmi/BHbRuBqgJPPvYu6iyQYFbBlYiBJY+ceiHGx+5jyL5c+4mdi/+xkj 5tY+rp7lfFk3m3fdvaVf5nWKAWOt0EHWfaQGjftrxSp1nOvimvD3FUFSfvhtkRJP2F SYQYyH5Z0Ie2nMmd75zlWkia1RRN71fV7ws+oYngLbWacmtFKrQfnHlbiBrZ2i9c1j ix8zy0qTVIUUctKGImbgEDc+ZJMuzGaLtMWkoFbbskES4XwxGpDRbc6lJlM1zzMoZq /Frh1/+PMrzMg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2ADD3180589 for ; Wed, 19 Jun 2024 15:31:12 +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=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (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 ; Wed, 19 Jun 2024 15:31:11 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id B735A13801BC for ; Wed, 19 Jun 2024 11:29:57 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Wed, 19 Jun 2024 11:29:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1718810997; x= 1718897397; bh=gR2L2HOYQXPUQ15lgjguPg8xEqNwoJBxx9lisgaVEqA=; b=i eK0V9lOPcUl8G3zgvLIUe8UfwYWKck6fgnBiuBJlqRr4zauGD4ssydvk1ofjFFOT 0wXSpJYFQzIGWRQzYWduPZQUCaomhBJskc6exsaX/3f4X+3sNvCQ20q3Y53QR/Gz vuWk9KXcBpmnd80YwKd5tj83qnwLKvhvqYd6tuSDrFJsYC73x12DUOs4BoKk9YVm 9EZPlMyLBKf4zsVw72/ILAT0u57VZb9HNmIsLKzg2U0SbY0x9A/Lr1xNP44CjLvk BqEsUY+A46Iyt68lzSaB16OIyjPKoqMmUZA+TuvjUu19U5OsOMLnMUmhFnPzMosw PRrXlFfwXBl0gR07SsbiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1718810997; x=1718897397; bh=gR2L2HOYQXPUQ15lgjguPg8xEqNw oJBxx9lisgaVEqA=; b=o4TLCyxmh8HoPSWbYJC1ubgkEoX5PAwa4z6TBT1FKFHr aFA9+zlYbBGeWnmXkJFmpaLte9U7OvSWRN7xbpiK+PKp022tcHdjUCc6Pe1yIA6p EACIyHTfsO3v6Z1WEdFP4qBqPG2bygjQtdqcPjgS4yirZ3kLMGOwUh9z6M46GhDJ dtXZ4yHmlag7/Ud0FncQCyoZCsTKsDFj9GzQEJjjXaHbcpjKFkkT1kI2yQwtg9sQ InfDtl9wsywD7qdgglDz95seLE91k1M0wrzvoVVzjAO5AhavaMoKV61tOO1Tqo0x 4a13+EN8+mHe3GXs+sQ6hA+p0xDqs+GJ2nzUNCWOpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeeftddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeevheehvdevjeelvdevgfelvefftdejkeelvdekgeeh fffgiedvjefhhfeltdduteenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhi vghlughtvggthhdrtghomh X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 492471700093; Wed, 19 Jun 2024 11:29:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <4545f838-11a6-4f2c-bf62-c6bdb2b5172f@app.fastmail.com> In-Reply-To: References: Date: Wed, 19 Jun 2024 10:29:37 -0500 To: "php internals" Subject: Re: [PHP-DEV] [RFC] Static Constructor Content-Type: text/plain From: larry@garfieldtech.com ("Larry Garfield") On Wed, Jun 19, 2024, at 7:33 AM, Erick de Azevedo Lima wrote: > Hello everybody. > > I found myself wanting this feature (that I first encountered when > programming in C#) for removing a workaround from a codebase I work > from time to time. > I searched internals and found a discussion from almost a decade ago. > That discussion did not end well, mostly because of insulting > accusations. > I then decided to do some research on this subject and found out that > it's a pretty common feature in other OOP languages. > Also, as I started studying the php-src (and missed the days when I > used to program in C in my main job), I decided to do an implementation > myself even before presenting the RFC. > The implementation link can also be found at the RFC. > > You can read the RFC here: > https://wiki.php.net/rfc/static_constructor > > Regards, > > Erick Unsurprisingly, I have concerns. :-) Perhaps surprisingly, I don't outright hate it. In particular, the examples you show are on the edge of what I'd consider valid use cases: More complex initialization of things like lookup tables or "dynamic constants" (like if you wanted to record "now" to use for later comparisons). For that reason, therefore, I don't like the current approach, especially for this line: "Programmers have the option to call the __staticConstruct method to reset static properties values if desired." It's screwy enough that you can explicitly call __construct(). I wouldn't want to perpetuate that weirdness. It also feels like it leaves the door open to more abuse than is tolerable. As some of the comments note, half the use cases would necessarily involve reaching out to some global state (file system, DB, etc.), which is already problematic, especially for testing. Which also brings up another question: How would one even mock this? If I can't test it, I can't use it. I would favor the "Java 2" style: Referencing a static method that will be called to initialize the value. That makes it clearer what is happening and encourages the intended path/use case: Lazy property initialization. It also avoids a "big blob" function in favor of small, specific functions. It also allows the author to more easily decide if they want to expose that logic to child classes for overriding: Make it private or protected, as they prefer. (Public I am fine with forbidding.) A few other notes: Your examples would be clearer if you leveraged the ??= operator, which would reduce your initializeMinDate() methods to a single line. I also take issue with this paragraph: > Object-oriented languages like Java, which adhere more strictly to object-oriented principles, include static properties and offer mechanisms for their initialization with non-trivial expressions. Java uses method calls or static blocks for this purpose, as will be demonstrated later in this text, illustrating that even in environments stricter about OOP principles than PHP, static properties are sometimes useful and require appropriate initialization methods. Not because other languages are wrong to reference; I do so very frequently, and do consider "everyone else is doing it" to be a useful (though not always winning) argument. What I object to is holding up Java as being "stricter about OO principles." OO principles are not a uniform, monolithic thing. In fact, the person who invented the term Object-Oriented has said before that C++ and Java are *not* what he had in mind. "Class based programming" is not what OOP was intended to be. OOP is about "message passing," which is often forgotten or misunderstood or ignored. Also, my day job is now working in Kotlin, which means I am faced with a lot of Java code I have to interact with. To be polite, holding up "Java style" design as anything to emulate is... a categorical error. Referencing other languages is fine, do that (and I appreciate that you did; I didn't realize this was so common a feature, and that does help make me amenable to it), but please do not in any way suggest that Java is the definition of "good and proper OOP." It is extremely not. I'm still not sold on the idea, but... I think I could be, which is more than I expected from the title. --Larry Garfield