You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The up_by(), down_by(), etc. "shifting member functions" for Posn construct a new Posn modified from the existing one as specified. I've found that this doesn't match student's expectations that they will modify the Posn they are called on.
It also doesn't match my own expectations. If they were named from_up_by() similarly to the functions of Rect, I think that they would make more sense. Or if they actually modified they Posn 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?
The text was updated successfully, but these errors were encountered:
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).
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?The text was updated successfully, but these errors were encountered: