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 <[email protected]> wrote: > On Tue, May 26, 2015 at 9:38 PM, Peter Uhnák <[email protected]> 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 > >
