Larry, Your absolutes and comments like "Relying on global mutable state is a bug" are incredibly frustrating. Are the authors of Carbon and Chronos, the two biggest userland time libraries, somehow wrong because they aren’t you? Do you think they didn’t put any thought into their decisions and just relied on global mutable state for no reason?
There are multiple internal functions that rely on global state, such as date_default_timezone_set(), date_default_timezone_get(), mktime(), gmmktime(), setlocale(), localeconv(), set_error_handler(), restore_error_handler(), set_exception_handler(), restore_exception_handler(), session_start(), session_destroy(), session_set_save_handler(), session_id(), srand(), rand(), mt_srand(), mt_rand(), stream_context_create(), stream_context_set_option(), stream_context_set_params(), ob_start(), ob_get_contents(), ob_get_clean(), ob_flush(), ob_end_flush(), import_request_variables(), ini_set(), ini_get(), ini_restore(), timezone_identifiers_list(), and timezone_name_from_abbr(), are those also to be considered bugs? Isn’t PSR a recommendation, not a mandate? How can it be "the correct answer"? (we get it, you're a member of PHP-FIG) You don’t make any effort to help or provide constructive criticism; you just love to (incorrectly) tell everyone what they're doing wrong and how they should be doing it, without adding anything constructive to the conversation. Cheers, Lanre On Mon, Jul 1, 2024 at 12:13 PM Larry Garfield <la...@garfieldtech.com> wrote: > On Mon, Jul 1, 2024, at 3:56 PM, Go Kudo wrote: > > > I apologize, the main point of my explanation was off. > > > > To put it simply, I'm suggesting that it might be good to implement > > convenient and commonly used features from Carbon at the ext-date level. > > > > I'm proposing the date_test_set_now() function for the following reasons: > > > > User-land libraries like Carbon / Chronos have a setTestNow method, > > indicating a potential demand for this feature. > > It's impossible to determine whether a value is relative or absolute > > time from either user-land or Extension. > > While this is convenient for maintaining legacy systems, that's not the > > essence of this proposal. > > > > As you pointed out, this is an issue that should ideally be solved in > > user-land. I deeply understand that. > > > > However, in reality, PHP's time-related processing is diverse, and to > > comprehensively handle all of these, it seems necessary to address this > > at the ext-date level. > > > > https://www.php.net/manual/en/ref.datetime.php > > > > For example, you might want to use the date() function to display the > > current time on a whim. However, doing this ruins everything. > > > > Even if other parts of your code use Carbon or comply with PSR-20, > > using the date() function is problematic because the current time it > > references cannot be modified. > > > > `date_test_now(\DateInterval $shiftInterval)` can solve this problem. > > > > Of course, there might be various side effects. However, seeing > > `Carbon::setTestNow()` being used in various places, I think this > > feature might be necessary. > > > > I would appreciate your thoughts on this. > > > > Best Regards, > > Go Kudo > > They are unchanged. > > > For example, you might want to use the date() function to display the > > current time on a whim. > > So don't do that. Relying on global mutable state is a bug. That older > parts of the stdlib made that mistake doesn't mean we should continue it. > (See also the Random extension, which also works to avoid global mutable > state.) > > > Of course, there might be various side effects. > > Exactly. This is not something to just brush aside with a comment. > > The way Carbon does it is wrong, for the same reason: It just sets a > global state. The correct answer is to use PSR-20 and inject a fixed-time > instance of the Clock. > > --Larry Garfield >
