On Mon, Jul 1, 2024 at 12:42 PM Lanre <lnearw...@gmail.com> wrote: > 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 >> > My bad for the top post, still getting used to it. Also i think this RFC is a great idea and will be one less reason to use a third party userland library to handle time.
Cheers, Lanre
