Re:Good Design is Imperfect Design, Part 1: Honest Names
by ericevans on Wednesday August 04, 2021 @05:29PM
(#28066606)
Okay, I almost wish I hadn't read this comment because it is so similar to what I have in part 2! So please don't be annoyed when you see it in a couple of weeks ;-)
I actually separated it into a separate part because it undermines my primary point. Sure, we all love it when we have a better decomposition, better names, and everything falls into place. But it doesn't always. Not in the time we have. So then we need ways to deal with the flaws. I decided that if I had ended with this it would have communicated: Aw, just keep trying and you'll get something nice! That can be very risky.
Re:Good Design is Imperfect Design, Part 1: Honest Names
by ExtraE on Thursday August 05, 2021 @09:51AM
(#28073723)
Heh. You didn’t have a perfect example but you went with what you had and shipped.
Re:Good Design is Imperfect Design, Part 1: Honest Names
by stickfigure on Wednesday August 04, 2021 @06:02PM
(#28067008)
The only thing advanceBy has going for it is that when the programmer inevitably tries to type add (after wondering why plus turns up nothing), the IDE _might_ show it in a dropdown.
Re:Good Design is Imperfect Design, Part 1: Honest Names
by bottled_poe on Wednesday August 04, 2021 @06:36PM
(#28067336)
Ok, but that’s when you read the docs. Also, in many languages, those expected methods could be mocked out to raise compiler errors, redirecting the developer to the correct methods.
Re:Good Design is Imperfect Design, Part 1: Honest Names
by ummonk on Wednesday August 04, 2021 @09:13PM
(#28068549)
I’d argue it should be shiftBy rather than advanceBy to deal with negative periods, but yes. The issue here is the conflation of summing periods (commutative and associative) with shifting a date by a certain period.
None of the proposed names in the post actually clarify anything - they merely make the behavior seem more confusing.
One way to look at the issue is that the confusion stems from giving the same name to operators of different types, namely the "Instant plus Period" operator and the "Period plus Period" operator.
Period could be implemented as a vector with independent components for days, months, and so on. (I don't know if that's how JodaTime does it, but that's what I would do if I wanted it to have a "plus" operation.) Then it could have a well-defined operator appropriately named "plus", which is both commutative and associative as one would expect.
"Instant plus Period", however, is asymmetric, and cannot satisfy the identities we associate with "plus". So let's give it a name that is also asymmetric. How about "advanceBy"?
2021-01-30.advanceBy(1 month) = 2021-02-28
2021-01-30.advanceBy(1 month).advanceBy(1 month) = 2021-03-28
2021-01-30.advanceBy(1 month plus 1 month) = 2021-03-30
2021-01-30.advanceBy(2 months) = 2021-03-30
That seems much less mysterious to me. Sure, a casual reader wouldn't be immediately confident about what advanceBy returns in all cases, but giving it a name that conveys its asymmetry helps a lot.