No, I didn't change a single line - yet. There is no rush, but I want
everything to be properly communicated and discussed before doing any
sweeping code changes.
yep, there are. These classes are from before Sun was able to afford actual
> coders for making Java, and are also based on the fact that java.util.*had
> classes added to it with class names I was already using elsewhere. Their
> implementation of Queue was so shitty and slow and the lack of a
> StringTreeMap so annoying that I made these classes
I guess, you mean it was from quite some time ago. AFAIK, Java collections
has been around for awhile. Lack of Maps, well probably was also ages ago.
I also do not understand what is ArrayModifier class for? Is it dynamic
> array implementation? If so, there is better way to do it.
> No. But thanks for lecturing me. Oh, and I already knew all of the above
Fine, I was making sure you know where I am coming from.
Also, what is motivation for extending StringPrintStream?
> It was used in code you removed
Ok, then it is not useful then.
> I think you totally wasted your time pondering this stuff, writing this
> and my time answering it. All these classes are from applet coding. They
> implement features which were not available in all target JREs or are
> not available, are substitutions for bad implementations, run with fewer
> problems than their Java equivalents, and / or run / ran faster. Sun did
> excellent job running Java into the ground. Should I ever code anything
> again after JDecker I'll probably switch to another language for it
Well, I can decide for myself what is good way t spend my time, thank you
Nobody said Java is the end to solve all problems. Some problems can indeed
be solved by other languages. But that is besides the point.
> how any of this helps unravel the C++ AIcode.
Actually it is fairly simple and straitforward. I will write another mail on
it, so it is not cluttered with irrelevant stuff.
> I have said it before, and say it again : there is no right or wrong
> code beyond the questions "does it work?
Actually, it is not true. Code has different qualities - as readability,
extensibility and so on. Some are more important in one kind of projects,
others in another. So, just 'making it work' is not good enough, since it is
not making it work that is tough, but extending, bugfixing and updating is.
> is it maintainable to the neccessary extend?"
Depends, I would say, apart from you at the moment, nobody can maintain the
whole codebase, because too much is in your head and not in repository, code
comments, or documented elsewhere. So, to sum up - NO, it is not
> I'm currently considering whether any of the above makes the code harder
> to maintain.
In fact it does. I am not telepath (yet, unfortunately), so I have no way of
knowing why the class exists. If there could be at least a few sentences
describing what it does and why not the other way, it would be much easier
for everyone and new contributors in particular.
Any code increases complexity and effort to understand it. Less code ->
simpler software -> less bugs, easier to join and contribute.
> I just hope JDecker won't fall apart
> until after I have left it behind
It won't be any worse than it is now, one way or another.