Any why not use the language features that are already there first before asking for new ones? That code is pretty 1.4ish. Why not do
List<ShopItem> powerups = PowerupFeature.getPowerups();
List<ShopItem> available = new ArrayList<ShopItem>(powerups.size());
// We just want the available powerups
for (ShopItem pf:powerups) {
if (pf.isAvailable() || DEBUG) {
available.add(pf);
}
}
buildShopItems(available);
At least it simplifies the loop, gets rid of the cast/get-combination and is type-safe.
What Thought was always missing from the Collection classes, are internal iterators. Your average iterator is pretty inefficient, as both hasNext() and next() require exactly the same checks.
If we’d have:
someList.traverse(new ElementTraverser()
{
public void element(T t)
{
}
});
and
someMap.traverse(new MapTraverser<K, V>()
{
public void mapping(K k, V v)
{
Oh, I’m still stuck at 1.4 for game code thanks to the Mac legacy
But seriously, anyone who’s used SQL would tend to find the expressiveness of SQL select/insert/delete statements far more easy to understand than mentally having to work out what an iterator’s doing, and so on and on. It’d hide all that tedious stuff and just let you get on with succinctly specifying the logic of the operation rather than the minutae of how it actually goes about doing it.
And let’s face it, C# is making some wonderful inroads in this area, as it is in all sorts of other areas. We’re only talking an optional syntax here that the compiler can support too, not changing any existing stuff.
Why bother with Retroweaver nowadays when javac will do it for you? Just need to compile with -target jsr14. Of course, you’ll still need to check that you don’t use post-1.4 methods. I don’t know a tool to do that, although writing one is easy (assuming you have the 1.4 libraries to test against, and that you’re not using reflection).
In Eclipse, right-click on the project, select Properties. There is a section called Java Compiler. You can set the compiler compliance level there to say, 1.4. Of course this means you cannot use features newer than 1.4, unlike when using Retroweaver, for example.
I only consider that a tiny bit more readable than going through the loop. I can’t imagine how horrible the code could end up looking inside a class that actually accesses a database, or all the bad habits it could end up teaching people to use.
I’m kind of shocked that nobody has come out against the crowd and agreed with you yet, Cas - your example requires far fewer keystrokes, is more understandable, and omits all the crap boilerplate that makes maintaining and extending most Java code a nightmare. I don’t see what’s not to like, except that it’s different from the way things are done now.
I don’t know if everyone really thinks the Java “solutions” aren’t that ugly or what, but I’ve personally felt a lot of pain over similar things in Java (filtering and selection are always a bitch since you have to wrap functions in objects in order to pass them around), and I think this would be a seriously useful improvement to the language.
Nothing at all against that code, it’s perfectly fine as far as Java code goes, but “just like a FileFilter” is exactly the problem - there’s no way to do it better in Java, and that sucks.
In Scala it’s worth implementing convenience functions like “select” (or in Scala’s case, filter) because I can write
myList.filter( enemy => enemy.life > 0 )
to get a list of living enemies with zero hassle. Once I have to write
to do the same thing in Java, the abstraction has lost pretty much 100% of its convenience value, since the unabstracted code:
List<Enemy> alive = new ArrayList<Enemy>();
for (Enemy e:myList) {
if (e.life>0) alive.add(e);
}
accomplishes the same thing and actually uses less code than the “properly” abstracted version. The only gain is that if the types of filters you use are very restricted, you can pre-write parameterized classes like LivingEnemySelector, etc., saving you a bit of typing. But from what I tend to see, filtering operations tend to be one-off deals, so you get very little ROI by writing concrete selector classes instead of just inlining them.
Hopefully Java 7 will include proper closures and add a new chapter to this story…
I think deep down it’s the same reasons as Hibernate exists - a deep seated fear that graduate programmers have of SQL, never having properly been taught it in situ with some real world problems to solve it remains enigmatic and scary to most Java programmers. If you’ve been doing SQL for any reasonable length of time you soon come to appreciate how obvious it is for set-based logical operations like for example that big thread on entity systems recently as an alternative programming paradigm.
Not just that but it’d make the whole entity-relationship mapping thing a piece of piss and Hibernate could be slowly tortured to death, as befits it.
There’s quite an impedance mismatch between Java and SQL, and more generally between the OO and relational database approaches themselves, so I think that’s understandable, however unfortunate.
But this stuff should be bread and butter for any language used in enterprise, and that’s Java’s main target, so I’m not sure why it hasn’t been addressed more seriously before. The cynic in me thinks that Java’s movers and shakers prefer to do as little moving and shaking as possible these days - it’s real easy to avoid criticism if you don’t do anything at all! Hence the calls to just use libraries instead of changing the language, which (to be fair) are often quite valid.
This particular issue goes deeper than what libraries can accomplish, though - it requires major ease of use to change the way people approach problems, so as long as it’s even minorly inconvenient or ugly to deal with set operations as core logic, people will never do it unless they absolutely have to, and even the they won’t like it. Which really sucks, since many problems are most appropriately dealt with in terms of list and set ops, especially the types of data-centric problems that are becoming more and more prevalent as we end up swamped in more data than we know what to do with.
I yearn for a little more control over syntax in Java…DSLs are wonderfully expressive, and I wish we could create our own without leaving the language, that would actually allow for stuff like this to be in a library. Not holding my breath, though…
fwiw, I think princec and ewjordan are spot on.
I used to think that LINQ just cluttered the language by solving a problem that can better be solved with a library, until I realized how much flexibility and readability it adds. Princec’s example demonstrates quite nicely how such a language change can solve the problem in a much cleaner, flexible and readable way than a library possibly can.
