Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124157 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 CB8E21A009C for ; Mon, 1 Jul 2024 18:42:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719859419; bh=B+DOlVZ7BQNTC2YZVA5BYsYA/XXmEUg7jdf56jUUSW0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Im8ko8VmcgTvnHK3fEcbJvr+AeMd24cNVsBtAEVcp6jMUoxIN6sM31eRAJrgXNQUk SyAGOm1eWM+2YIILvIR5BuOZeAPgSXw7zUYkwX/74fFzQhPcRqJ+T5PoIFtxrKqABW YALlMauBoZ+N5a/I6agwl2SLBrjZoYZjdScjDj+iEgZpuEhxXmf6MYcCyCMfmpFE66 +zYT0XNJnes0YSXoSXOEFoDj/1gViz+SbvqcBTukPe/iBys/eY2UFjXyljw/JfFgtQ b/RBF9QjdFBYcQ9mygqJ6ZluVtsKEfww0grg3gfV8e0KdMrvSWi6/VgcCr5SKW2n54 ea5v2FbfjOEcw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 90CBE1806FA for ; Mon, 1 Jul 2024 18:43:36 +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.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,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 mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 ; Mon, 1 Jul 2024 18:43:36 +0000 (UTC) Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-48f5d1c2341so1831349137.0 for ; Mon, 01 Jul 2024 11:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719859334; x=1720464134; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Afmfm542F3rgjolkHmqsy9RFeDtIElgJyf/lF0FxiIU=; b=NjB5OtzGf+XGNzoaCsT5z+YFZoJ/GPKmIWD6ro4AElo/tYR8JYm3pqr1Ckwd0bJ8M6 JpOOv8wLlbXKthQQHd8OlgbuhsY25kV/KwJqazcdlkijife3RSbKtWnqTyEcqluKky8N VgXnys4df/x7Ez55Pm2fvC8xjWHX9OSFtFcwSUrKUfSTsEPEeo13oB2ncTBVl9plz4XA RU2LWjGIw2D0xusqHSrYEtCDYl47sMVMSUHmCpJ8206X3LIVlbo++zOOh73oJFuZMFPw 8cpykTRTP2OuKedx2nH3n8ErsMg8tnIZR6k2ToHPtUZbwlX51sCVlkeJr+5ffDIwEayo 5kWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719859334; x=1720464134; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Afmfm542F3rgjolkHmqsy9RFeDtIElgJyf/lF0FxiIU=; b=mW9OOtMAyUWr6LLK9UYlLYF51SWz7YFKaGcx42x7egH+dh0RHjseNd9TK8Xtf8NZMI NVV3yXO65aANUmnpGqpVe69wD4x17S3splsOQ6tMMRujq+4ox7PAUhljVvkmRz+eS+qr hm6qJM6B2Tsy5s9SQ7MfvXFfmHppzq8QIa/TW7CtssPuMohHJ0s4l0RzEebxLfB5bVud mqXa6RSqPybI006TyoQ/NrUzdPw10g9wGoE8iVnLtstjS3ob/VsUKQcHFqL+tRMnvl0y vreAxVEoJDqDcKcJF6yllMJwuV5jJvNiw9V4rDGyq8hFy7jOTYovZxWQjZMDZXjMiHL5 T/eA== X-Gm-Message-State: AOJu0YzvVNxY05aqe5VVWpP+lQihOpVLBwx6OjwqcBL635GUwZpHfCWf Mc35KVPg3f8XmyPOYkeYIKmCYTEyDoQGga4BQk/+3CFjl6jPmodkqyAM0Tt651pYizFlqgzaWGa IcZArTb/ae5c3poX2JtmMr/sY/RQ= X-Google-Smtp-Source: AGHT+IHU+WWh8hLDrD7Gi26CbcWYDAmaoI+ky3l8F7ucLHzq3CxDV2iR7Htfosku+JE9V4CwFWuDT5ksE5sxBOqzCWo= X-Received: by 2002:a05:6102:38ca:b0:48f:62bb:357c with SMTP id ada2fe7eead31-48f9e8421a3mr8117005137.3.1719859334571; Mon, 01 Jul 2024 11:42:14 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 1 Jul 2024 12:42:03 -0600 Message-ID: Subject: Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000b36e90061c33f4a3" From: lnearwaju@gmail.com (Lanre) --000000000000b36e90061c33f4a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t = you? Do you think they didn=E2=80=99t 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=E2=80=99t PSR a recommendation, not a mandate? How can it be "the corre= ct answer"? (we get it, you're a member of PHP-FIG) You don=E2=80=99t 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=E2=80=AFPM Larry Garfield 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 reason= s: > > > > 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-tim= e > instance of the Clock. > > --Larry Garfield > --000000000000b36e90061c33f4a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Larry,

Your absolutes and comments like "Rel= ying 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=E2=80=99t you? Do you think they didn=E2= =80=99t put any thought into their decisions and just relied on global muta= ble state for no reason?

There are multiple internal functions that r= ely on global state, such as date_default_timezone_set(), date_default_timezone_get(), mktime(), gmmktime= (), setlocale(), localeconv(), set_e= rror_handler(), restore_error_handler(), set_exce= ption_handler(), restore_exception_handler(), ses= sion_start(), session_destroy(), session_set_save= _handler(), session_id(), srand(), r= and(), mt_srand(), mt_rand(), stream= _context_create(), stream_context_set_option(), s= tream_context_set_params(), ob_start(), ob_get_co= ntents(), ob_get_clean(), ob_flush(), ob_end_flush(), import_request_variables(), ini= _set(), ini_get(), ini_restore(), ti= mezone_identifiers_list(), and timezone_name_from_abbr(), are = those also to be considered bugs?

Isn=E2=80=99t PSR a recommen= dation, not a mandate? How can it be "the correct answer"? (we ge= t it, you're a member of PHP-FIG)

You don=E2=80=99t make any effo= rt to help or provide constructive criticism; you just love to (incorrectly= ) tell everyone what they're doing wrong and how they should be doing i= t, without adding anything constructive to the conversation.

Cheers,<= /p>

Lanre


On Mon, Jul 1, 2024 at 12:13=E2=80=AFPM Larry Garfield <= larry@garfieldtech.com> wr= ote:
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 implemen= t
> convenient and commonly used features from Carbon at the ext-date leve= l.
>
> I'm proposing the date_test_set_now() function for the following r= easons:
>
> 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 absolu= te
> time from either user-land or Extension.
> While this is convenient for maintaining legacy systems, that's no= t 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 thi= s
> 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 <= br> > references cannot be modified.
>
> `date_test_now(\DateInterval $shiftInterval)` can solve this problem.<= br> >
> 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.=C2=A0

> For example, you might want to use the date() function to display the =
> current time on a whim.

So don't do that.=C2=A0 Relying on global mutable state is a bug.=C2=A0= That older parts of the stdlib made that mistake doesn't mean we shoul= d continue it.=C2=A0 (See also the Random extension, which also works to av= oid global mutable state.)

> Of course, there might be various side effects.

Exactly.=C2=A0 This is not something to just brush aside with a comment.=C2= =A0

The way Carbon does it is wrong, for the same reason: It just sets a global= state.=C2=A0 The correct answer is to use PSR-20 and inject a fixed-time i= nstance of the Clock.

--Larry Garfield
--000000000000b36e90061c33f4a3--