Replace Deprecated methods removed as 'unused'

[uckelman]

Thus spake Flint1b:
> You mean like, at runtime find out which of our stuff is deprecated,
> then find out whether the currently running module uses any of it?

Something like that, yes.

If we could display a dialog notifying the user that a module uses
something deprecated and they should contact the module's maintainer
about that, I have good reason to believe modules will get adjusted.

> Possible, yes, but is it worth the trouble?

That depends on how much work it is, and how much work it would save.
I don't have a sense of what the ways of doing it are and how much
work they would be.

--
J.

[Flint1b]

First thing that comes to mind is to use this deprecate-analysis tool that I've found, the one that we used to determine the unused dependencies. Take that in as a library and write code on top of that, basically doing the same thing we did by calling that tool from a shell script. This would probably be the easiest to implement.

Other options would be to use some other code analysis library, like asm or cglib, I think we already have asm (or was it cglib?) in the libraries, beanshell brings it along. But we would have to reinvent the wheel with that, write the whole analysis code from scratch.

[uckelman]

Thus spake Flint1b:
> First thing that comes to mind is to use this deprecate-analysis tool
> that I've found, the one that we used to determine the unused
> dependencies. Take that in as a library and write code on top of that,
> basically doing the same thing we did by calling that tool from a shell
> script. This would probably be the easiest to implement.
>
> Other options would be to use some other code analysis library, like asm
> or cglib, I think we already have asm (or was it cglib?) in the
> libraries, beanshell brings it along. But we would have to reinvent the
> wheel with that, write the whole analysis code from scratch.

Something depends on cglib... possibly mockito?

I suppose the stupid-simple thing would be to add a line to each of the
deprecated methods which raises the disableable problem dialog.

--
J.

[Flint1b]

How sure are you that the users would pay attention to technobabble and contact the module developers? I can imagine they will be frightened the first couple times but realize that nothing is broken and they can still play as usual, then get used to it and just click it away.

I am still more convinced by the "crash the car into the wall" strategy, this is what is needed to get the module developers to wake up. I would just prepare for this a little, maybe sth like a big announcement "in case your module doesn't work with new version - a) here is Vassal 3.2.17 download, use that b) contact module developers".

[uckelman]

Thus spake Flint1b:
> How sure are you that the users would pay attention to technobabble and
> contact the module developers? I can imagine they will be frightened the
> first couple times but realize that nothing is broken and they can still
> play as usual, then get used to it and just click it away.

* Module developers are likely to see the message themselves when they
try their modules. Some of the problems will be fixed by module
developers as a result.

* It's not necessary for every user to understand the message for it to
be effective. It won't take very many users contacting module designers
about problems before it becomes quite annoying for them, to the point
that it will be less annoying to fix the problem.

We haven't had many questions about custom classes being compiled with
the wrong version of Java since we added the warning dialog for that.
It's a similar situation, so I expect a similar result if we add a
warning for using deprecated methods and classes.

> I am still more convinced by the "crash the car into the wall" strategy,
> this is what is needed to get the module developers to wake up. I would
> just prepare for this a little, maybe sth like a big announcement "in
> case your module doesn't work with new version - a) here is Vassal
> 3.2.17 download, use that b) contact module developers".

Removing currently deprecated methods _is_ that strategy. What we're
talking about is how to let module designers and users know what to do in
a way that doesn't ruffle a lot of feathers or become a huge time suck
for us.

--
J.

[Brent Easton]

> How sure are you that the users would pay attention to technobabble and contact the module developers? I

This approach was extremely effective because the messages where so damned annoying and scary for non-techno users.

I suppose the stupid-simple thing would be to add a line to each of the deprecated methods which raises the disableable problem dialog.

This is not only the minimum work and most efficient solution (No need for startup scanning), it could also be extremely effective if you get a popup the first time each new Deprecated method is run, even if you disabled the popup for the last one. Very annoying. I would rather we annoy the hell out of the users of these modules than break them altogether.

The most effect Shareware force payment scheme I've ever seen was one where there was a 1 second delay on program startup that increased by 1 second every day or two. You thought you could live with it, but after a couple of weeks it drove you mad.