[josm-dev] Jumbo Patch

[Gabriel Ebner]

On Mon, Dec 17, 2007 at 10:17:35AM +1100, Brent Easton wrote:
> >AFAIK the last time we broke some plugins was with the API 0.5 changes. 
> 
> I believe it happens more regularly than that.

Do you have any examples?  I just reviewed recent bug reports.  We got many
people whose mappaint plugin couldn't find the Segment class.

Then, two months ago, I (rather unnecessarily; shame on me) broke the
validator plugin for a short time for those who were running the very latest
versions.  If you didn't update for a week, you wouldn't even have noticed it.

(During the cleanup of the plugins directory in SVN someone recompiled all
plugins for Java 1.6 thereby rendering them unreadable for Java 1.5; but
that's not JOSM's fault.)

> >And I
> >don't know how we could have prevented that.  If a plugins wants to add a
> >segment, but neither JOSM nor the server use them anymore, there simply
> >isn't
> >a way to make this work easily.
> 
> 
> Well, there is. If the segments where being added via a standard call, that
> call could have been just changed to do nothing.

Which would have broken them too, at the latest when it would try to combine
them into a way.

> >Unfortunately pretty much all of the code that operates on the data set
> >makes
> >intricate assumptions about the inner workings, even simple changes like
> >adding a node to a way make delicate assumptions about the way JOSM undos
> >them.
> 
> That's where the mistake lies.

Mistake?  I didn't defend that design.  In fact, I'd love to get rid of it.

> No, I don't think anyone is suggesting that adding a bunch of
> getter/setter's is going to fix the flaws in the current structure. I don't
> think that is what this discussion is about.

At least the heated part is.  :-)

> Getters/setter is one tool in the toolbox for building a more maintainable,
> less bug-ridden structure. 

Yes, by themselves they cannot turn intertwined code into separable pieces.
What's needed is a sensible structure, as you said.
 
> Someone claimed that adding setter/getters would add hundred's of lines to
> their source files. If you have to add that many, then the code is organised
> wrongly. The 'intelligence' needs to bought down into the lower level
> objects.

100 lines of code are just 33 getters and setters, i.e. 16 variables (even
less if we take blank lines into account).

> I have reached situations like this many times. My gut feeling is that the
> JOSM core needs to be redesigned. Conceptually, in the greater scheme of
> things, what JOSM does is not that complex and it should be possible to come
> up with a highly optimized, extensible core that does everything needed. If
> this where to go ahead, then it would make sense to design this with OO
> principles in mind to make it maintainable. If a new plugin or piece of code
> needs to hook into something in the core in a non-standard way, then we add
> the appropriate hooks into the core to allow this to happen.

This might really be worth a try.  OsmPrimitive is full of variables that are
either "not used", as the comments state it, or "really for future use only"
(since May).

So what would that core need to provide?
  - data structures, 
  - undo/redo support
  - uploading (marking deleted and modified objects)
  - merging
  - rendering optimizations (special representation, indices) / hooks for that

Did I miss anything?

  Gabriel.