On Wed, Mar 3, 2021 at 8:42 AM Andreas Heigl <andr...@heigl.org> wrote:
>
> Am 03.03.21 um 14:24 schrieb Moritz Friedrich:
> >
> >
> >> Am 03.03.2021 um 14:01 schrieb Andreas Heigl <andr...@heigl.org>:
> >>
> >> 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 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’d 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’d 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 = 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 = new \DateTime();
$format = "Ymdhis";
echo $dt->format($format);
$s = $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 = $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:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org |
> +---------------------------------------------------------------------+
> | https://hei.gl/appointmentwithandreas |
> +---------------------------------------------------------------------+
>
>
--
Chase Peeler
chasepee...@gmail.com
