I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers.
Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). Richard On Oct 4, 2013, at 12:46 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Yes, that pretty much captures the thinking behind it. > > My thought is that there is no real reason that subdivisions need to be > immutable, although I wouldn't want to change it at this late date for FX 8 > unless it is needed for FXML support. > > The fixedEyeAtCameraZero mode is not something I think should be mutable, > since the camera behaves fairly differently in each mode. Having said that, > there is no reason it couldn't be made mutable in a subsequent release if > there was a good reason to do so. > > -- Kevin > > > Chien Yang wrote: >> We did discuss making divisions in the predefined 3D shapes mutable in >> earlier meeting. However we decided against it since it is a heavy weight >> operation as the supporting mesh will has to be regenerated. I believe the >> constructor with the divisions argument will not have much use in the future >> when we move away from mesh implementation of our predefined 3D shapes. >> >> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the >> camera and once set it shouldn't be changed. The perspective projection >> matrix is constructed differently depending on the flag. In the default >> mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that >> simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, >> where eye is fixed a camera zero, is well suitable for movable camera in the >> 3d space. >> >> - Chien >> >> On 10/4/2013 9:28 AM, Richard Bair wrote: >>> Why are they not? It isn't immediately obvious to me why these are not >>> mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and >>> this struck me as odd. >>> >>> Richard
