It is not at all unusual for getBar() to have subtle differences from being simply "return bar;" These are not necessarily what one would consider "side effects", but there's often a reason for getBar() to exist and do something more than "return bar;". For instance, bar might be of the same type as getBar(), but getBar() might do some sort of cleansing of bar for external use. bar might be a collection and getBar() might well return a copy or a non-modifiable wrapper around bar. In any of these cases, having code suddenly switch in meaning from foo.bar to foo.getBar() could be disastrous to the code's behavior.
Which is why I believe uniform access is fine and (quite) good, but must use "->" not "." lest it wreak havoc on existing code and produce subtly but nastily different meanings from the same Java code compiled with / without the uniform "."-based access. If "." had meant uniform access for the last decade of Java's lifespan, that would be fine. At this point trying to introduce this would cause a royal mess. -- Jess Holle Kevin Wright wrote: > 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. > > > > -- 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.
