translateBy: vs translatedBy:
In Pharo 4.0, there is a Rectangle>>translateBy: aFactor method. The same method in VW is called translatedBy: In Pharo, there is also a translatedToBeWithin: and translatedAndSquishedToBeWithin: and scaledBy: Just to be consistent, this is maybe better to use translatedBy: instead of translateBy: ? -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Hi Serge, I vote for renaming to Rectangle>>translatedBy:, because it returns a new translated rectangle instance. For example in bloc there is BlUserInputEvent and it has two methods: translateBy: and translatedBy:. First one actually modifies position (mutates object) the second one creates a translated copy of the event. Hence Rectangle is suppose to be immutable I think translatedBy: is better name. Cheers, Alex On Tue, May 26, 2015 at 2:41 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
In Pharo 4.0, there is a Rectangle>>translateBy: aFactor method. The same method in VW is called translatedBy:
In Pharo, there is also a translatedToBeWithin: and translatedAndSquishedToBeWithin: and scaledBy:
Just to be consistent, this is maybe better to use translatedBy: instead of translateBy: ?
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
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. If anything, the whole Rectangle API would have to be changed, as there is plethora of similar methods (expandBy:, extendBy:, merge:, etc.) 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. Peter
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
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
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
On Wed, May 27, 2015 at 1:16 AM, Peter Uhnák <i.uhnak@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
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 <btc@openinworld.com> wrote:
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
On Wed, May 27, 2015 at 1:16 AM, Peter Uhnák <i.uhnak@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
On Wed, May 27, 2015 at 8:51 PM, Damien Pollet <damien.pollet@gmail.com> 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 <btc@openinworld.com> wrote:
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
On Wed, May 27, 2015 at 1:16 AM, Peter Uhnák <i.uhnak@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
participants (5)
-
Aliaksei Syrel -
Ben Coman -
Damien Pollet -
Peter Uhnák -
Serge Stinckwich