My comment is not intended to say that such systems are either good or bad, but to simply point out the fact that it is an important design desision. Increasing the memory footprint increases the number of cache & page missing that will occur. Is this important? Maybe yes, maybe no. It depends on a number of factors, such as access patterns and the number of active entities.

Performance is overrated, unless it's an issue. There are tons of possible systems, of which "faking" cross-cutting concerns in an OO language is simply one solution. To toss out another, a simple data-driven model can handle the majority of the concerns addressed by cross-cuts..and it's simpler to write and maintain. It is superior? Well, like all game related questions...it depends.

When should I use a flavor of hash-table or a binary tree? Which is "better"? They have similar usages, but the best choice, well, depends.

That's all you would do. So any component can have a parent (that it can access if it needs to), and/or it can have a lot of child components. So you can get a nice tree structure in there in terms of how things are formatted which can work very well with renderers, etc. if you make it work nicely enough (great for boned animations and the like).

I would say that IMO making cross component access will be requiered in a lot of case (as pointed above by Demonpants code), like if you got three components : sensor, visibility & position in the system that manage visibility you will want to read the position and in the system that manage sensor you will also want to read position. In my case I have found interresting to have an entity class that is accessible from any of its components, this way a component know its entity and can give access to others components owned by this entity ( I told about its implementation here http://www.java-gaming.org/topics/efficient-caching-for-entity-system/22011/view.html), It is now implemented and working , it give excellent performance and it is very easy to use or build system.

I always get frustrated by generics when I try and build them into my own classes. They have bad limitations with arrays, and the <> tags become messy as soon as you start having nested generified types like lists of lists.

But they not only save lots of typing, make your code clearer and catch many potential run-time bugs at compile time (like potential class cast exceptions).

I fully agree they have limitations, and I'd like to see them go further, but IMHO there are no negatives in using generics. They are even backwards compatible with pre-generics JVMs.

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no? Not to forget that Java generics do a whole lot of type casting under the hood, so you might as well just make your own ArrayList implementation (this is what Kev always does) to avoid all potential problems and overhead.

I personally use generics usually, but that's because they typically save me programming time. The whole reason I posted the FYI was so that Dreamcatchermatt would know all the facts before spending the time learning generics.

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no?

Yes generics are not available at runtime, but I still disagree that they can't prevent runtime errors.

The old example of using generics with a list shows this. This non-generics code will fail at runtime:

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no? Not to forget that Java generics do a whole lot of type casting under the hood, so you might as well just make your own ArrayList implementation (this is what Kev always does) to avoid all potential problems and overhead.

Good point about performance, since that isn't at all obvious from the beginning. I typically only avoid generics for performance critical things, since using generics is quicker to code for most situations. You might have to explain the "getting runtime errors instead of compiler errors". Looking at your code, changing:

1

doubleQueue.push (newDouble (2.0));

to

1

doubleQueue.push (newInteger (2));

will create a compile time error when you use generics, but a runtime error in your other example when you didn't use generics. And that is probably what JL235 was talking about. I am sure he meant "catch" as in prevent, not "try - catch"). I don't see how generics could create a ClassCastException even though the the Lists loose the type after compile, since you can't create code with different types for the same List.

Yeah, I mean you guys are right that they certainly prevent you from making most mistakes, but I would argue that the runtime exceptions that you will get from generics are much more difficult to track down because in order to make them happen you need to have some pretty complicated (or weird) code paths. They're not catch-all because they don't actually make an object that only allows one type, they just constrain it when you happen to be modifying that object in a scope that has generics defined for it. I have had several cases over the years where I am somehow modifying a Collection that has generics but without using generics. i.e. it gets modified like Collection<Object>. This has required some tricky code paths and passing of the Collection between lots of functions and other things, but it has indeed happened to me. The fact of the matter is, if you can somehow "trick" the compiler that you have a Collection<Object> even though you may have a Collection<Integer>, then you can put whatever you want in there with no problems, and expect it to be perfect because there are no compiler errors reported.

Anyway. Let me reiterate - I almost always use generics. I never make code critical-path enough to worry about the flaws of them.

The fact of the matter is, if you can somehow "trick" the compiler that you have a Collection<Object> even though you may have a Collection<Integer>, then you can put whatever you want in there with no problems, and expect it to be perfect because there are no compiler errors reported.

Good point about performance, since that isn't at all obvious from the beginning. I typically only avoid generics for performance critical things, since using generics is quicker to code for most situations. You might have to explain the "getting runtime errors instead of compiler errors". Looking at your code, changing:

Using the standard java.util collections both with or without generics should always give the same performance.

At a guess I believe what you might actually have found an issue with is the overhead of auto-boxing primitive types. I'm pretty skeptical generics itself was causing any performance issues in your code, as all it adds are a few extra casts which you'd typically need to add to your non-generics code anyway. I've also rolled plenty of my own collections to get this small performance gain.

What's sent is an array list of Object, even though Comparable is passed as the template. So what comes in is also an ArrayList of Object, even though it gets cast (yes, you will get a compiler warning) to an ArrayList of Integer. The above would obviously be a silly mistake, but situations like these in complex projects are more what I'm talking about. It makes much more sense to just have like a ServerDataList object that has customer methods to only allow what you want and then send that around instead. Or just stick with ArrayList<Object> and know that it may not be safe (like you would always assume with ArrayList<Object>) so you can check each and every Object's type.

and this could also be achieved through composition, or by creating your own object input/output streams which solved the type issues for you (i.e. they only took and returned a type of ArrayList<Comparable> allowing developers to avoid doing the cast themselves).

I do see what your saying, it is an example of generics failing to solve a type problem. But this issue will just as easily crop up in a system which didn't use generics.

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors

If you use generics and you have no compiler warnings then you can never get a ClassCastException. Ever. However, jumping through all the hoops and typing all the goddamn pointy brackets is not worth it to solve this "ClassCastException problem", which never really existed.

My approach is to turn off the warnings that are stupid, and to just use generics for syntatic sugar. Doing this you are no worse off ClassCastException-wise than pre-Java 1.5, but you have a little sugar. We all know Java could use some sugar.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org