Open brghena opened 2 years ago
Yes, this was the intended behavior. I think the intent was for them to get some practice with a non-mutating API like this. But if you think it’s too confusing, I would be open to one of a few different changes:
We could rename the functions from up_by
to above_by
.
We could change the signatures from
Posn up_by(Coord) const;
to
Posn& up_by(Coord);
We could get rid of them entirely, since they’re mostly redundant with Posn Posn::operator+(Dims) const
and Posn& Posn::operator+(Dims)
.
What do you think?
The
up_by()
,down_by()
, etc. "shifting member functions" forPosn
construct a newPosn
modified from the existing one as specified. I've found that this doesn't match student's expectations that they will modify thePosn
they are called on.It also doesn't match my own expectations. If they were named
from_up_by()
similarly to the functions ofRect
, I think that they would make more sense. Or if they actually modified theyPosn
they are called on.Is it intentional behavior that the shifting member functions create a new
Posn
rather than modifying the one they are called on?