Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » [GEF4] Immutable geometry primitives
[GEF4] Immutable geometry primitives [message #1736502] Wed, 29 June 2016 21:24 Go to next message
Stanislav Golubtsov is currently offline Stanislav GolubtsovFriend
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 Go to previous message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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,
Previous Topic:MvcUiModule dependency on PlatformUI
Next Topic:GEF4 Zest in Eclipse 4 RCP
Goto Forum:

Current Time: Mon Oct 18 09:08:31 GMT 2021

Powered by FUDForum. Page generated in 0.01897 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top