pt_assistant: use builder pattern for TestError

[simon04]

Please update the plugin to use the builder pattern for TestError, which has been added in #13799/r11129.

Your plugin is the only one creating TestErrors and we'd like to remove the deprecated code eventually.

[darya]

Thanks for the message, working on it.

[darya]

Fixed, new revision [o33082].

[Don-vip]

In 11309/josm:

see #14015 see #13799 - remove deprecated stuff

[darya]

I understand the need for the builder to make sure the TestError always has primitives and a message. But why should it be impossible to change the error message later?

This is where I use the TestError.setMessage() method in the pt_assistant plugin:

In step#1 I check for each route relation if it is continuous. If not, a TestError is created, with all the "primitives" and "highlighted" objects that belong to it.

In step#2 I check if some of those non-continuous route relations can be fixed based on other continuous ones. Depending on how many fix variants there are (0, 1 or >1), pt_assistant will ask for a different type of response from the user. At this stage, I want to change the error message accordingly (0, 1 or >1 fixes available).

In other words, I cannot set the right message before I have visited all route relations. If the TestError.setMessage() method is gone, then I have to create a new TestError every time I just want to change the message, and update the Collections that contain that TestError => things slow down.

[simon04]

The idea of #13799 is to make TestError an immutable class. Before calling TestError.Builder#build you are free to modify TestError.Builder#message/TestError.Builder#messageWithManuallyTranslatedDescriptionas often as desired.

[darya]

Replying to simon04:

The idea of #13799 is to make TestError an immutable class. Before calling TestError.Builder#build you are free to modify TestError.Builder#message/TestError.Builder#messageWithManuallyTranslatedDescriptionas often as desired.

Ok, thanks for the answer, I'll try that.