On Wed, May 27, 2015 at 8:51 PM, Damien Pollet <[email protected]> wrote:
> 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?
Hard to be perfect but maybe...
Extract pairs of past participle (p.p.)[1] and transitive verb (v.t.)
[1] from a dictionary like [2],
e.g. Merged (imp. & p.p.) of Merge
Merge (v.t.) to absorb.
and if the method...
A. returns same object -- check its method name is (v.t.) form
B. returns different object of same species -- check form is (p.p.)
C. returns different type of object -- ignore.
Actually maybe coverage doesn't need to be perfect. There just needs
to be enough consistency that the convention can relied on (and
publicised!), and humans can update rules for edges cases as they are
arise.
cheers -ben
[1] http://en.wiktionary.org/wiki/Wiktionary:Abbreviations_in_Webster
[2] http://www.mso.anu.edu.au/~ralph/OPTED/v003/wb1913_m.html
[3] http://www.mso.anu.edu.au/~ralph/OPTED/
>
> On 27 May 2015 at 01:14, Ben Coman <[email protected]> wrote:
>>
>> >
>> > 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
>> >>
>> >
>>
>>
>> On Wed, May 27, 2015 at 1:16 AM, Peter Uhnák <[email protected]> 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
