Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
Graf Zahl said:
I don't understand why you had to hack around that (at least that's how I understand this sentence.)
Ok, back to the roots:
mobj_t (one of the many implicit "subclasses" of thinker_t) contains a thinker_t struct at its beginning, not a pointer. This means that, in C and C++ you can pass either type around and treat it as an union of sorts, even if you DON'T do an explicit mobj_t->thinker access. Aka if you pass a mobj_t where a thinker_t is expected it won't complain, and will work as intended.
In code terms:
code:
public class thinker_t {
public thinker_t prev;
public thinker_t next;
public think_t function;
}
public class mobj_t extends thinker_t implements Interceptable {
...(snip)...
/* List: thinker links. */
//public thinker_t thinker;
...(snip)...
}
Focus on that commented out thinker_t: if I leave it in and DON'T extend thinker_t instead, I won't be able to pass and cast mobj_t into thinker_t, and I surely won't be able to access any of its fields. Yes, I admit to not using a pure OO approach here and a lot of stuff is accessed directly through fields, at least at first.
Similarly:
code:
public abstract class SectorAction extends thinker_t {
public sector_t sector;
}
public class fireflicker_t extends SectorAction{
public int count;
public int maxlight;
public int minlight;
}
Focusing on that fireflicker_t, I noticed that in ZDoom it has become DFireFlicker and essentially contains the sector actions "inside it", rather than leaving it in the equivalent of r_specs, without losing context. In Java, depending on how much global crap it needs to access, I'd have to make it internal to the class containing the various "global" variables, or else devise (yet another) way of passing context around. I prefer keeping it simple, for now ;-)
If I want to pass mobj_t's or "sector actions" as thinker_t's around, they must either implement an interface (but then, in Java, interfaces cannot define member fields or implement functions except class static ones) so I'd have to hack around that anyway. Abstract classes can do both, but like interfaces, they cannot be instantiated (maybe C++'s meaning is different?), so I must extend an abstract class with those fields.
Maybe this "daisy chain inheritance" appears weird, but remember than in Java you don't have true multiple inheritance.
I checked out ZDoom's code to see what you mean though, and I saw you took it to a whole new level: you're using a much more OO approach to Thinkers (including iterator patterns, which are nowhere as efficient or automatic in Java as they are in C++) so we're really comparing apples to oranges here, as I'm not changing the internal mechanics to that degree (yet): it's weird that you call my approach a "hack" though, when you are dealing with a much more complex and layered system in ZDoom (than again ZDoom has a much broader scope, so whatever works best I guess). If someone else wants to make a "Java ZDoom" however, hey, be my guest :-p
Last edited by Maes on 11-22-10 at 12:10
|
11-12-10 13:48 
