That's not all, many methods return new rectangles via Point's API, namely Point>>{#corner: #extent: #rectangle:}

I don't know if I can perform static analysis of the code (are there tools for that in Pharo?) to see which methods exactly return Rectangle

rectMethods := #(#corner: #extent: #rectangle:).
(Point methods select: [ :m | rectMethods includes: m selector ] thenCollect: [ :m | m senders ]) flattened select: [ :s | s className = #Rectangle ]. "an Array(
Rectangle>>#areasOutside:
Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit:
Rectangle>>#withBottom:
Rectangle>>#bottom:
Rectangle>>#areasOverlapingOutside:
Rectangle>>#floor
Rectangle>>#allAreasOutsideList:startingAt:do:
Rectangle>>#scaledAndCenteredIn:
Rectangle>>#squishedWithin:
Rectangle>>#ceiling
Rectangle>>#withHeight:
Rectangle>>#rectanglesAt:height:
Rectangle>>#scaleFrom:to:
Rectangle>>#withLeft:
Rectangle>>#left:
Rectangle>>#withTop:
Rectangle>>#right:
Rectangle>>#top:
Rectangle>>#innerCorners
Rectangle>>#interpolateTo:at:
Rectangle>>#withWidth:
Rectangle>>#quickMergePoint:
Rectangle>>#withRight:
Rectangle>>#rotateBy:centerAt:
Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit:
Rectangle>>#flipBy:centerAt:)
"

This list is maybe a bit excessive (sometimes it returns self, sometimes new rectangle -- e.g. floor).


On Tue, May 26, 2015 at 6:14 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, May 26, 2015 at 9:38 PM, Peter Uhn��k <i.uhnak@gmail.com> wrote:
>> I vote for renaming to Rectangle>>translatedBy:, because it returns a new
>> translated rectangle instance.
>
>
> -1
> There is no benefit in renaming a single method, apart from creating more
> confusion.

I wouldn't say "no benefit".�� Consistent conventions are beneficial.
It could be useful to bring these into line with the general "-ed"
convention of returning a new object.�� �� �� I don't see how this would
create confusion, though it might create work.�� Whether its worth the
work is a slightly different question.

> If anything, the whole Rectangle API would have to be changed, as there is
> plethora of similar methods (expandBy:, extendBy:, merge:, etc.)

For a better feel of the work involved...

Rectangle methods select: [ :m | m sourceCode includesSubstring: '^
Rectangle ' ].
�� �� Rectangle>>#intersect:
�� �� Rectangle>>#quickMerge:
�� �� Rectangle>>#encompass:
�� �� Rectangle>>#intersect:ifNone:

Rectangle methods select: [ :m | m sourceCode includesSubstring:
'^Rectangle ' ].
�� �� Rectangle>>#intersect:
�� �� Rectangle>>#translateBy:
�� �� Rectangle>>#scaleBy:
�� �� Rectangle>>#merge:
�� �� Rectangle>>#compressTo:
�� �� Rectangle>>#expandTo:
�� �� Rectangle>>#roundTo:
�� �� Rectangle>>#truncateTo:

The following already follow the convention...
�� �� Rectangle>>#compressed
�� �� Rectangle>>#expanded
�� �� Rectangle>>#rounded
�� �� Rectangle>>#truncated

> Pretty much all Rectangle messages are immutable and create new Rectangle,
> thus I feel it is unnecessary to state it explicitly.
>
> In VW there is plenty of methods (e.g. left:) that mutates it, thus unlike
> Pharo a clear distinction is required.

Still, it is reasonable to consider the impact of inconsistent
conventions on the rest of the system outside of Rectangle.

cheers -ben