ComparisonTrait::isSameDay() / ComparisonTrait::isSameMonth()

[Andrii Pukhalevych]

chronos/src/Traits/ComparisonTrait.php

Lines 406 to 409 in b130b9b

 public function isSameDay(ChronosInterface $dt): bool 
 { 
     return $this->toDateString() === $dt->toDateString(); 
 } 

Why in ComparisonTrait::isSameDay(), instead of comparing day/month/year, there is called FormattingTrait::toDateString() with FormattingTrait::format() inside, that looks much expensive operation?

Should it be following:
return $this->year === $dt->year && $this->month === $dt->month && $this->day === $dt->day; ?

And should not we add one more method ComparisonTrait::isSameMonth()? I need such method in current project, but it does not present.
That will return $this->year === $dt->year && $this->month === $dt->month? It will be possible to use it inside ComparisonTrait::isSameDay().

[Mark Story]

Why in ComparisonTrait::isSameDay(), instead of comparing day/month/year, there is called FormattingTrait::toDateString() with FormattingTrait::format() inside, that looks much expensive operation?

I'm not sure we have sound reasoning as to why those methods are implemented the way they are. A large amount of the chronos project was inherited from Carbon. Changing the implementation around seems safe to me, and would likely be more efficient.

And should not we add one more method ComparisonTrait::isSameMonth()? I need such method in current project, but it does not present.

The only rationale I would have to not add more methods is that the Chronos is already a very wide class/interface. I don't feel that is a strong argument though. Any chance you'd be willing to make pull requests for these changes?

[Oliver Nowak]

I have serious doubts that this would perform better. Currently it's 4 nested method calls, 2 x toDateString(), and 2 x format(). Using magic properties would result in 12 nested method calls, 6 x __get(), and 6 x format().