Scala case classes *are* exposing methods, it's just that the getter for 'x' is named 'x' and the field is kept very well hidden... If you want javabean-style properties then you can use the @BeanProperty or @BeanInfo annotations
And why should it matter if foo.bar is a field or a method, so long as the method is free from side-effects? Of course, there may be performance considerations for calculated members, but this smells far too much like premature optimization to me. By keeping names uniform, it becomes possible to change your mind at a later point and not have to refactor the users of your class. On Nov 24, 10:43 am, Jess Holle <[email protected]> wrote: > hlovatt wrote: > > The problem I have had is that I did originally want a struct of a > > certain structure, but then I changed my mind. For example I once made > > a Complex type this way with real and imaginary final fields, problem > > was I latter found that I was always multiplying and not adding the > > complex numbers. Then I wished I had magnitude and phase fields (which > > make multiplication easy). If I had used getters and setters I could > > have changed. > > > The thing that appeals about final fields is the short syntax both for > > writing the class and for accessing the fields, Scala style uniform > > access and case classes anyone. > > > NB > > > 1. Scala case classes aren't exactly what I would want since they > > expose the final fields, it would be better if the case classes only > > exposed the getters. > > > 2. I can hear someone from the posse screaming properties in the > > background :) > > I can see where adding -> field/property dereferencing (no, "." will not > work well here as foo.bar would radically change meaning from what it > means today where one has access to the "bar" field) would be a nice > solution here. With the right load time semantics built into the JVM, > one could presumably figure out the right access approach once (field or > get method) and use it from thereon without further lookup overhead. > > That aspect of the nebulous properties stuff (nebulous = oh, I meant > events too and automatic event listeners and....) seems reasonably > straightforward and helpful to add. > > In the mean time I use public final fields for "localized" value > classes, i.e. those used in a fairly small scope. If the class is used > broadly I tend towards getters and private fields to reduce the > potential need for refactoring later. > > -- > Jess Holle- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
