On 6 May 2013 15:21, Alexandre Bergel alexandre.bergel@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.
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.
that's not the point. The point is that the user-to-screen space transformation is given by Athens. (actually it is maintained by backend directly, and transformation happens only when necessary during rendering cycle by graphics engine itself). A user is free to use any coordinate system he wants and don't need to convert them manually, he just needs to use transformation he desiring, and draw all geometry using own coordinates. Needless to say, that computations at primitive level is much more efficient than at smalltalk level.
For having nested (hierarchical) transformations , you just modify the matrix (once), when you go into one level deeper. So, you still have result := v*M instead of calculating result := v*M1*M2
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?
How does this related to modularity?
Or.. you think it will be more modular, if you introduce "DiagonalArrow".. and then since it can be drawn in 4 quadrants, you will need DiagonalArrow1stQuadrant DiagonalArrow2ndQuadrant DiagonalArrow3rdtQuadrant DiagonalArrow4thtQuadrant
and since you need reverse, you will need
DiagonalArrow1stQuadrantReversed DiagonalArrow2ndQuadrantReversed DiagonalArrow3rdtQuadrantReversed DiagonalArrow4thtQuadrantReversed
? You still don't see that there's something wrong with approach?
Having symbols such as #orientation and a boolean reversed?
Why you need orientation flag? The arrow direction can be defined by order of points which you passing to it. If you swap order, you will swap direction. And no need for flag. Simple , isn't?
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.