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