2016-04-28 A problem with storing commands

I knew that at some point I’d hit some wall… Of course, I will overcome this issue, but right now I feel quite lost. Here’s the thing: I want to be able to store some commands for the turtle (like “first go forward 5 times, then turn right 2 times, then go forward 1 times” etc.). I already know how to use an ArrayList or similar structures, but what should I store there?

In C, it would be easy: I would just store a struct with two integer fields: one holding type of the command (equal to one of a few constants defined to be subsequent integers) and another one holding the argument (“number of times” the command should be executed).

In Java, I have a vague feeling that this should be an object;-). However, currently I honestly don’t know how I should do this.

I guess the most Java-ish way would be to have an abstract class representing a generic “command”, and then have a bunch of its descendants representing concrete ones. The abstract class should have a method called “execute” or something like that, which would actually e.g. draw a line, turn the turtle etc. This way, my buttons – instead of doing things – would just add relevant commands to a list of commands, and then I could loop through this list, calling the abovementioned method, and that’s it! (As an added bonus, this would make “undo” quite trivial.)

But… how do I actually do that? In Java, you generally put each class in its own file. I’m pretty sure it would be stupid to do it this way – why have a lot of small files with small classes which shouldn’t be even visible to most of the code?

From what I google, the way to go would be “nested” or “inner” classes. But I have zero experience with them, and in particular, I don’t know how to write them properly. Should they all be inner classes of Turtle? If yes, should they be invisible for the outside world? If yes, how do I access them from the methods called by button clicks? (I guess Turtle should expose some kind of interface to all this stuff.)

And here is the paradox. AFAIK, one of the design goals of Java was to make programming “easy” (whatever that means). Wikipedia says that the first “primary goal” of Java was for it to be “simple, object-oriented, and familiar”. Seriously? Yes, it is object-oriented. (As a Lisper, I don’t want to speak of “familiar”, though knowing a bit of C I have to say it’s probably not that bad.) But calling it “simple” is really a bad joke.

You know, one of the design goals of Org-mode, one of my favourite tools, was that if a user doesn’t need (or want) some complicated feature (of which Org-mode has a ton), it mustn’t get in the way. Lisp is similar. You don’t need object orientation? Don’t touch CLOS. You don’t need closures? Don’t use them. You don’t need FORMAT or LOOP? Don’t even bother to learn their syntax.

OK, enough complaining for now. It’s too late today, but tomorrow I’m going to start researching my problem. I’m pretty sure I’ll find some tutorial/book chapter/blog post with some real-life examples of nested classes to get a feeling of how they are done (not only syntax, which can be found in the official docs, but good practices/caveats and that sort of things) and then I hope to grok the subject and produce some decent code.

Also, a short announcement. It seems that I’m going to be quite busy for the next few months, due to reasons unrelated to the contest, and I will have to cut down my time for Logeox. I hope that I won’t drop it completely. I’m determined to at least bring it to the state where it is “complete” as a drawing toy, not necessarily as a programming toy. (Also, I do not want to drop out of the contest!) Do not, however, expect a lot of new code in the near future. Sorry, this is life…

CategoryEnglish, CategoryBlog, CategoryMakeYourselfKnown