Other than maybe a log statement or cache lookup, I think that I'd condone flogging for anyone who wrote a getBar() method with side effects :)
Even a permissions check would have to be very well argued, as it can behave differently based on the context. The problem is that getBar() with side-effects *already* breaks expected behaviour. On Nov 24, 11:30 am, Jess Holle <[email protected]> wrote: > Kevin Wright wrote: > > 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? > > It only matters to the mountains of existing Java code in cases where > the method is not free from side effects, which are numerous. If all > usages of foo.bar suddenly started means foo.getBar() [assuming there is > a getBar()] in Java lots of code would break. Worse, more code would > mean something subtly different such that a change to getBar() to have > side-effects would do something completely different in Java versions > prior to such a change and after. > > It does not matter at all to a new language forming new rules. > > -- > Jess Holle -- 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.
