There is a discussion of such idioms in the I will present at ESUG. I only
looked at the API of String, but I'm sure most naming idioms apply to any
class. The question is, how do you ensure they are applied and complete?

On 27 May 2015 at 01:14, Ben Coman <b...@openinworld.com> wrote:

> >
> > On Tue, May 26, 2015 at 6:14 PM, Ben Coman <b...@openinworld.com> wrote:
> >>
> >> On Tue, May 26, 2015 at 9:38 PM, Peter Uhnák <i.uh...@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
> >>
> >
>
>
> On Wed, May 27, 2015 at 1:16 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
> > 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).
> >
>
> Good   Point   ;)
>
> However the "-ed" convention doesn't make sense for many of those...
>     #areasdOutside: , #areasedOutside , #areaOutsided:  ?
> ... and #areasOutside is obviously a different rectangle than the original.
>
> The scope might be restricted to only those where the usual convention
> makes the names misleading, for example:
>    #merge
>
> cheers -ben
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Reply via email to