Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113343 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32378 invoked from network); 3 Mar 2021 13:34:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Mar 2021 13:34:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3D4A31804DF for ; Wed, 3 Mar 2021 05:24:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_20,DKIM_INVALID, DKIM_SIGNED,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail.hades.9dev.de (mail.hades.9dev.de [88.99.187.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 3 Mar 2021 05:24:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 00DCE5DDD0; Wed, 3 Mar 2021 14:24:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9dev.de; s=dkim; t=1614777889; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=SFUTxx2AU0Q3ZIsM0YDfNzEPamE7qkU9Wl1xUpMyiH4=; b=RpbQNuzeEk+HdyReuqfuTqrB3RfGxyNdkjlJxKUoKXxgKbnctSGtFZ2tQZOfWTTt4bFmVL XqQLUF1ZOcMmWNJBjHs9rkj4+ZRBF4Mx9dG0kDrvDsj7ntdPaUQRlJLcDN2uqHPnOVssI5 tZ01mWT0NryGE479KktnEdhTPuB5xhTpNKmQ0l611mMWmBbC/1b4JCgEou01gbnq5jn1+y UMJ+GmoPuH4Pmma8BFNZpvIQ8mZNmQRbKHfH4iT0dE3bp9LV+wLHdl7mBRW/mDBfLVqgBe AjIN19ZAtiaz9qOrGaTxn2qNHXVCCy9YxFawx5EXSQH/P3SajvLyHkb0vJ570Q== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) In-Reply-To: Date: Wed, 3 Mar 2021 14:24:47 +0100 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: <434CA771-46ED-4219-A360-CC7E4A34EDDE@9dev.de> References: <09ef54b2-a6b1-5bf5-8562-f2f436fd4d92@processus.org> <9BF1EB68-3F1F-4FBF-A87F-FADF98B09E4A@9dev.de> To: Andreas Heigl X-Last-TLS-Session-Version: TLSv1.2 Subject: Re: [PHP-DEV] Add __toString() to DateInterval From: m@9dev.de (Moritz Friedrich) > Am 03.03.2021 um 14:01 schrieb Andreas Heigl : >=20 > I'd rather see those classes as ValueObjects that should not have to > take care about their external representation. And a custom Formatter > that handles all the weird edge cases as a separate entity would be a > much easier to maintain approach. And such a Formatter can easily be > build in userland (I think I wrote one myself at one point) and so the > maintenance-burden would also not be added to internals. >=20 > That would also apply to the DateTimeInterval::format() method but = that > would mean a massive BC break so it is most likely out of the = question. > Nevertheless I would prefer an external library to handle all those > formatting issues and treat the DateTime lib as internal ValueObjects I=E2=80=99d like to respectfully disagree. If we were to go down the = ValueObject route, DateTime/DateInterval should not be able to create = new instances from formatted strings in the first place. PHP Date = classes have always been intertwined with their output formatting = however, so this is how the ecosystem uses them. In that sense, I=E2=80=99= d expect DateInterval to be able to return the format it was = instantiated with, but it isn't. The PHP API may have its warts, but I prefer my warts consistent. Regards=20 Moritz=