Pinderkent

I recently saw an article about the accepted Project Coin changes that are planned to be included in JDK 7. This is some good news for the Java community. After a relatively long period of stagnation concerning the evolution of the Java language, and some fierce competition from C#, these are the sort of practical changes we need to see.

Most of these proposed changes aren't exactly revolutionary. Several of them have already been implemented for some time in C# and other .NET-based languages. They've proven to be effective there, and will hopefully bring the same benefits to Java.

The Automatic Resource Management proposal is a good example of a feature that is badly needed in Java. The using statement of C#, and the Using statement of VB.NET, have proven this concept. They make it safe and easy to ensure that certain non-memory resources are disposed of appropriately. This is exactly the sort of practical language-level change that Java needs.

The Strings in Switch proposal is another one that suggests a very useful change. Not being able to use a switch statement to select a case based on a string value has always been an annoyance to me.

The Improved Type Inference for Generic Instance Creation proposal may help making coding quicker, although I'm not convinced it's as beneficial as it sounds. Although it reduces what some may consider to be redundancy in code, most decent Java IDEs offer auto-completion support that helps prevent a programmer from actually typing out the parameterized types. And we do lose some detail within the object instantiation code, which otherwise is self-documenting in some sense. I think the benefits of this change will require some experimentation once an implementation is available.

Some of the other proposed changes, such as the addition of language support for JSR 292 and the collection-related changes don't seem as sensible to me. In the case of adding more support to the JVM and the Java language for supporting dynamically typed languages, I think this is a bad idea. The JVM itself is better suited to statically typed languages, and trying to hack on support for dynamically typed languages may just result in further bloat.

In the case of the collection-related changes, we are getting to the point where a major reworking of the collection classes is in order. We already have older classes like java.util.Hashtable and java.util.Vector, as well as the Java Collections Framework, and then all the changes that were made to both groups during the introduction of generics with Java 5. Trying to further build on the existing mess may just make the situation worse. But a clean up would be massive, and would have many repercussions on existing software. So there may be no easy answer here.

The acceptance of these proposals is a very good sign. They show the sort of activity and change needed to keep the Java programming language and platform relevant in the face of numerous other competing programming languages and platforms. I do hope that we get to see these implemented in JDK 7, as some of them do sound to be practical and badly needed by Java developers.

The recent 6 Signs of Adaptive PHP article gives some examples of different PHP coding techniques. Unfortunately, it only bothers to cover the supposed "benefits" of each, without any consideration of how such techniques can prove to be problematic.

The first technique suggests passing all arguments to a function within a single associative array. The supposed "benefits" all promote laziness, namely in that all parameters become potentially optional, and less or no change is needed to any invocations of the function if parameter changes are made.

Not mentioned in that article were the drawbacks. One obvious problem is the vastly increased verbosity, both when it comes to handling default values, and when it comes to invoking the function. Default parameter values, as offered by languages like C++ and even VB.NET, are syntactically superior to this approach.

Even the very concept itself is flawed, as it's much better in terms of maintainability and clarity to have an explicit list of parameters. For one thing, this technique makes it much less obvious to other programmers how to call the function. Given the general lack of documentation associated with most PHP applications, it's likely that anybody wishing to use the function would have to consult the code of the function itself. It also inhibits the ability of the interpreter to check that the correct number of arguments have been passed to the function.

Furthermore, if one has a function that has so many optional parameters that such a technique is needed, perhaps too much is being done in that single function. It would appear that such a function is a good candidate for heavy refactoring.

The second suggestion recommends checking for functions and classes before making use of them, such as those exposed by a plugin module. This sounds risky. When it comes to plugins, the host application should insist that any plugins conform to a strict API. Working with plugins that may just decide not to export a certain required function, for instance, is a recipe for disaster. If a plugin module doesn't provide the proper interface, it should not be loaded.

The third suggestion is perhaps the only one that's sensible. It suggests using require_once() to prevent multiple inclusions of some external PHP code. Indeed, this typically is a good idea.

The fourth suggestion recommends that associative arrays be used to return multiple values from a function. While this isn't as bad of an idea as the use of an associative array to store parameter values, this seems to indicate that PHP should offer a more lightweight construct such as the tuples found in languages like Python and Standard ML. Sticking with what PHP already offers, perhaps even an object could be returned, rather than an associative array.

The fifth suggestion recommends the use of an __autoload function. The very existence of this function suggests that PHP has some serious shortcomings when it comes to allowing for the sensible separation of code. On one hand, this sort of dynamic loading is the sort of functionality that PHP should offer transparently.

Furthermore, it indicates a laziness on the part of PHP developers who wish to write code making use of classes defined in other source files, but who are unwilling to put forth the small amount of effort needed to explicitly include such files.

In addition, the three notes in the __autoload documentation should make developers hesitant to use such functionality. It appears that it interferes with the semantics of exception handling, it's not available when using PHP in its interactive mode, and has risks associated with the validity of the class names passed to it. Frankly, it sounds like yet another PHP "bandage" meant to patch over problems in the language and programmer laziness, while at the same time introducing far more severe problems.

The final suggestion recommends that the directory of the script be determined by calling dirname(_FILE), especially for the purposes of location other PHP files to include. For the given example, the use of a relative path should be sufficient.

The PHP community has a long history of not fixing the problems with their language and its most common implementation. Far too often we've seen "solutions" like these, which end up being messier and more convoluted than had the problem with PHP itself just been fixed sensibly. It's no wonder that so many PHP Web apps are buggy, full of security holes and essentially unmaintainable; the language itself is inherently broken, the workarounds are just as broken and full of caveats, and together they result in nothing but problems.