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 additions
Do 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.