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
