On May 6, 2013, at 3:21 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
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.
did you try the code snippet of igor that I sent to the list?
Because you can zoom in a vector graphics polymetric view.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev