decker-jdecker — everything JDecker related

Re: [Decker-jdecker] Some aspects of required code refactoring for JDecker

[Vasilij S. <vas...@gm...>]

Greetings,

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
> mail
> 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
> still
> not available, are substitutions for bad implementations, run with fewer
> problems than their Java equivalents, and / or run / ran faster. Sun did
> an
> 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
very much.

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
maintainable.


> 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.

Regards,
Vasilij Savin

[Decker-jdecker] Some aspects of required code refactoring for JDecker

[Vasilij S. <vas...@gm...>]

Greetings,

Decker list for historical purposes.

I was going through code just before going to bed and found some fairly
fascinating things.

Are there any particular reason you are re-implementing basic Java stuff?
Because both Queue and StringTreeMap seem to be rather redundant.

Queue has implementation in Java. Here is the Javadoc for it:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractQueue.html

If I understood StringTreeMap properly you have implemented Map
functionality with Tree structure. Though motivation is not clear for me. I
would go with Map(http://java.sun.com/j2se/1.5.0/docs/api/java/util/Map.html)
as generic data structure and HashMap (
http://java.sun.com/j2se/1.5.0/docs/api/java/util/HashMap.html) as
implementation. I do believe Java engineers did a decent job implementing
this basic stuff properly.

I also do not understand what is ArrayModifier class for? Is it dynamic
array implementation? If so, there is better way to do it.

Also, what is motivation for extending StringPrintStream?

Regards,
Vasilij Savin

[Decker-jdecker] ICE behaviour

[Vasilij S. <vas...@gm...>]

Greetings,

Currently I am reviewing code for ICE behaviour. It is not pretty, but it
worked and is fairly straightforward.

In a few days to come, I am going to make some summary on how it works and
what can be improved in Jdecker version.

Regards,
Vasilij Savin