Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113349 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 48859 invoked from network); 3 Mar 2021 15:41:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Mar 2021 15:41:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B0DF0180542 for ; Wed, 3 Mar 2021 07:32:04 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 07:32:04 -0800 (PST) Received: by mail-vs1-f47.google.com with SMTP id l192so12780166vsd.5 for ; Wed, 03 Mar 2021 07:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s+0WumV407/iSS1pqyRePHDRhv09usgmsO4aLsPSI88=; b=VxLVSGn3t2rOZ4IFaVCub6zdjNYcnr/7zJBVisXmIL45GJV+MV9Na6l1I1Y02vd5/g tVkVEct9W3vIoiSXTgeCaUiYEf0Q9DVD+ZxEFvPHjLclE/YTYmz7+Xou50QEHSpQUcDF ECNyp6Cq6r1ew9N+Nh1hXMfeR10Ta88wCUPdrZxeHRVJYwxDPzKcEKRVgUxvjTZHbMDV DYO42GKtCg/e1kXIh8RblIL8Vej3DvMXQQctoerRhmQTMJlttFRrlGZmZG9Ybnd3imXA txUfur+c7I7rng21sw6uYneWh1HXO+nKW9VzrflFM4pgZL0sYK+JTcGNT5RVg3BTXm2i 5egQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s+0WumV407/iSS1pqyRePHDRhv09usgmsO4aLsPSI88=; b=Cbh7XFmiHE5Q896dTOiNvBIto+1jZb5/dIKP9Ee7sirLRE0/9s0bAUUjUThgcjH4+q dTFewaTrk6/ZBnevqesS9g7/J3PWY04io/35al3hFaB3Qt7pvfTpE7az7Y7aUA8EmTOb u57InblYqEPhrkw1YBv88xTTsBXJ0IRD3DpBqJgymBZqbzdrhUhedK7iSBdnPZ99XSdJ MLr4WpmSxN4qAZSi/pCrtbzkBWKCvrH4tICyQjIraagA/Y4mzkO0evhtPwAhzPMfiBRw S3UA4QBMB+h3eGoMhzmSsIGhK2OLanNSFJLf28sx4MqTX5Akv5UOZYuBRG+Icp7QHaCe vvTQ== X-Gm-Message-State: AOAM532MzKJU/9BIqKy6+0OO/ccnVzQGI1nwuMcmqgOCq8e0fckW2OMx iRoU7XcbiBghIJ1fOk3/YrhWvdts0+IHISTOZMs0EwsxKDM= X-Google-Smtp-Source: ABdhPJwbKpo0NUXgeQNXdJdhJ2tcVw1lDQJTvM/rMZUBy31elGdZa0xSVYmVdSLI+ef1TupV5CMPjUFwH24elYO7N9g= X-Received: by 2002:a67:1481:: with SMTP id 123mr6034182vsu.52.1614785521851; Wed, 03 Mar 2021 07:32:01 -0800 (PST) MIME-Version: 1.0 References: <09ef54b2-a6b1-5bf5-8562-f2f436fd4d92@processus.org> <9BF1EB68-3F1F-4FBF-A87F-FADF98B09E4A@9dev.de> <434CA771-46ED-4219-A360-CC7E4A34EDDE@9dev.de> <471b9142-7df6-6d64-0814-035f6e8252e1@heigl.org> In-Reply-To: <471b9142-7df6-6d64-0814-035f6e8252e1@heigl.org> Date: Wed, 3 Mar 2021 10:31:50 -0500 Message-ID: To: Andreas Heigl Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000006b1f6a05bca38db0" Subject: Re: [PHP-DEV] Add __toString() to DateInterval From: chasepeeler@gmail.com (Chase Peeler) --0000000000006b1f6a05bca38db0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 3, 2021 at 8:42 AM Andreas Heigl wrote: > > Am 03.03.21 um 14:24 schrieb Moritz Friedrich: > > > > > >> Am 03.03.2021 um 14:01 schrieb Andreas Heigl : > >> > >> 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. > >> > >> That would also apply to the DateTimeInterval::format() method but tha= t > >> 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 Va= lueObject > 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=99d expect DateInterval to be= able to > return the format it was instantiated with, but it isn't. > > Well. ValueObjects should be able to create new Instances of themselves > via factory methods. But that would mean a lot of tweaking at perhaps no > added benefit. > > But TBH: DateTimeImmutable:fromString() instead of new > DateTimeImmutable() would be awesome... Or even better: > DateTime::fromString() with DateTimeImmutable as return type > > > > The PHP API may have its warts, but I prefer my warts consistent. > > I feel you. > > As the other Objects have a format() method why not have a format method > for DatePeriod as well? It does not need to take a parameter as there > are no different formats (at least that I could think of). > > But I would rather not add more magic (methods) to PHP... > > I wouldn't call utilizing __toString() adding more magic methods to PHP. It's utilizing a magic method that already exists. I'd also argue that of all the magic methods, __toString() is probably the least likely to cause issues. 1.) Core/bundled extensions don't usually have major documentation issues 2.) Even if __toString() functionality isn't properly documented, I'm guessing (please prove me wrong if I am) that working with string output of an object that hasn't implented __toString() has hardly any use in production (not counting tests). As such, if __toString() were to magically appear (pun intended) the side effects would be minimal. 3.) Unlike some of the other magic methods (__get, __set, __call for instance) __toString() is basically implementing an interface from a user perspective. I personally like the idea of having more explicit methods and then allowing __toString() to invoke one of those. I don't know if I like this idea or not, but, just to throw it out there, when dealing with something like DateTime, you could even support the ability to set a "default" format that would be utilized by __toString (with the default format having a default value if not set) $dt =3D new \DateTime(); echo $dt; //outputs 2021-01-01T03:15:00-05:00 $dt->setDefaultFormat("Ymdhis"); echo $dt; //outputs 20210101031500 Considering that when I'm doing something and need frequent string representations of a DateTime that are always the same format, I usually do $dt =3D new \DateTime(); $format =3D "Ymdhis"; echo $dt->format($format); $s =3D $dt->format($format); The only thing you really risk with the setDefaultFormat() option is that you pass the DateTime to another method and they aren't really sure what is there and/or override your default format. I think as long as it's well documented, that could be easy to work around. function foo(\DateTime $dt){ $currentFormat =3D $dt->getDefaultFormat(); $dt->setDefaultFormat("m/d/Y"); //stuff $dt->setDefaultFormat($currentFormat); } Again, I'm not sold on such functionality, just throwing out some ideas to see what others thing. > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | > | https://andreas.heigl.org | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas | > +---------------------------------------------------------------------+ > > --=20 Chase Peeler chasepeeler@gmail.com --0000000000006b1f6a05bca38db0--