| [GEF4] Immutable geometry primitives [message #1736502] |
Wed, 29 June 2016 21:24  |
 Stanislav Golubtsov
Messages: 1
Registered: June 2016 |
Junior Member |
|
|
Hello Alexander,
I was wondering about the design decision to use mutable Point and other geometry primitives. On one hand, the mutable Point allows doing computations with smaller memory overhead.
On the other hand, the simple immutable objects have many advantages. You don't need to defensively copy the object in constructors and the getter methods. For any ordinary developer this is a big advantage in terms of code readability. It is also impossible to misuse methods like translate and getTranslated.
The general trend is headed towards even more concurrent computation (nowadays it is difficult to make a faster processor, but relatively easy to increase the number of cores), and here the immutable objects are the big help (see the new version of DateTime in Java 1.8, for instance).
Even if there is no issue with the UI thread using the mutable geometry primitives in GEF4 (but aren't animations using concurrency in JavaFX?), the developers might want to reuse the library as a standalone component in their projects, where the concurrent computation is more common.
Perhaps an ideal solution could be to use the companion objects (see the book on Effective Java by Joshua Bloch). The mutable point could be used for intence computations, while the immutable point version could be used for storing and passing in arguments.
|
|
|
| Re: [GEF4] Immutable geometry primitives [message #1742652 is a reply to message #1736502] |
Tue, 06 September 2016 11:30  |
|
Hi Stanislav,
when designing the Geometry API we had a few things in mind, concurrency was not on that list. It is mainly inspired by the defects of draw2d.geometry, i.e. integer coordinates (and the awkward Precision* classes), few geometric abstractions, and few geometric operations (e.g. points of intersections cannot be computed).
We are currently evaluating the addition of a notification mechanism within GEF Geometry, so that geometries can be observed for changes.
Other than that, the current API is not designed for immutability, i.e. Point and Dimension expose members publicly, and many manipulation methods are available to change a geometry in-place. Moreover, if we would introduce an ImmutablePoint and let Point extend ImmutablePoint, we would need to use ImmutablePoint in all places where mutability is not needed. I would rather extend Point and override all mutators, but that leaves the public members still in place.
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.05550 seconds
] 
Search
Help
Register
Login
Home
