[josm-dev] Jumbo Patch

[Gervase Markham]

Frederik Ramm wrote:
> I know the basic ideas & advantages behind encapsulation. Hotspot
> inlining stuff removes the runtime cost of it, but the code bloat
> remains; for everything that might have to be accessed from the
> outside, you need a getter and setter - and they carry *no* additional
> information, except the tiny percentage of getters and setters where
> you actually do something other than just reading or writing a private
> variable.

What do you mean by "code bloat" anyway? It's not like you need to 
_read_ this code. It just has to be there. Put it at the bottom of the 
class if you like. I'm sure you can't be worried about the extra 1 
second it takes to do a checkout, or the extra 5k it takes up on disk.

> Just as Hotspot inlines the stuff, the compiler could easily generate
> this on the fly where required so that I only have to explicitly write
> those methods where something happens. 

Well, it could, but in Java it doesn't, and that's just the way things 
are. If writing them is boring, I'm sure Brent or Petr will happily 
write them for you (or use their IDEs :-).

> The issue was exemplified by Dave's patch where he just wanted control
> over a tiny bit of all possible operations on the node list, but for
> this paid the price of adding getters and setters for near everything.
> If that isn't bloat, then what is?

Like I said, use an Adapter. Then he doesn't have to write all the 
additional getters and setters.

> I don't know which of the en-vogue programming paradigms this was but
> there is one that basically says "don't over-engineer, just write
> exactly the code you need to solve the problem at hand". I would like
> to be able to do that, write exactly the code required, instead of
> using 50% of my code lines to pave the way for something that might
> come in handy later. Or might not.

Over-engineering is not about added lines of code, it's about added code 
complexity. Getters and setters don't add _complexity_ - like you said, 
they are entirely trivial.

Gerv