I had some passing thoughts about Arrow hierarchy along the lines of... (from memory a while ago...)are you sure that v*M has more operations?Your matrixes are 2x2 ? I thought they would be 3x3, I haven't verified, by having 3x3 for 2d plans allows for zooming. But maybe you do not need since Athens handles this apart.AtthensAffineTransform>>transform: aPoint [ ... ] 4 multiplications 4 additionsDo you call #transform: just once per object? Roassal supports nesting of elements. So I guess you need at least two #transform:, one of the translation to the inner scope, and another for the global transformation.this makes sense only if both coordinate systems not rotated respective to each other. Once you have rotation, this method loses all geometrical sense and very dangerous to use.Yes, this does not work for rotation.* Point 3 about design ------------------------------ ROAbstractArrow ROArrow ROReversedArrow ROHorizontalArrow ROReversedHorizontalArrow ROVerticalArrow ROReversedVerticalArrow Why do we have all these classes? why they are not...... traits? Well... because there is little support in Pharo to work with traits. Another reason is traits exist only in Pharo.no, i was wondering why you need more than a single class, representing an arrow which connects two arbitrary points. Instead you have only horizontal or vertical + separate subclasses for different arrow direction.. so, either i don't understand something, or if i right, this needs to be thrown away.How could it be kept modular and simple if this is not by having subclasses? Having symbols such as #orientation and a boolean reversed? Alexandre