GWT Server-side Internationalization With Hermes

I recently made a post on my company’s blog about a new open source project I just released called Hermes. Here is a short excerpt:

Greetings interwebs! My name is Matt Bertolini and I am an engineer here at Travel Tripper. I thought it was about time I made an appearance on our tech blog. I want to talk about a new project I have recently finished and am sharing with the world.

A Little Backstory

Our application, RezTrip, is in the process of being internationalized. Since it is a GWT based application, we chose to use the GWT static string internationalization features. Unfortunately, these features only work on the GWT client-side and we have lots of other client-facing strings that need to be internationalized (client emails, legacy HTML pages, etc.).

The gwt-i18n-server Library

A quick Google search on the subject of “server-side GWT i18n” found a library called gwt-i18n-server. This library gives the server-side support for the GWT static string i18n interfaces and properties files. We quickly incorporated the library into RezTrip and found it was pretty buggy. Worse yet, development on the library had stagnated and hadn’t been updated in over a year. This is where I come in. Not satisfied with admitting defeat and implementing a separate i18n system just for server-side content, I decided to fork the gwt-i18n-server library and fix the bugs.

To read the rest of the story, click here.

PHP: Time To Break With the Past

A few weeks ago the Python Software Foundation released version 3.0 of the Python programming language. This was a big deal because version 3.0 broke backwards compatibility with the widely popular 2.x line of the language. Obviously, making the decision to break backwards compatibility was an extremely difficult one to make and many people have mixed feelings on the subject. My opinion on it is that the break is a good thing. The changes made to the language make it better and the way the organization is making the transition is smart.

But this post is not about Python, but another programming language: PHP. Unlike the Python Software Foundation, the PHP group have made some poor decisions about their language and I believe it is hurting the language and will ultimately lead to their downfall. I think it is time for PHP to do exactly what Python did and break backwards compatibility.

Now I don’t claim to be an expert in the inner workings of the PHP organization but I am a user of the language. I program all of my web sites in PHP and I have written a few applications in full object orientated PHP 5. I can say that trying to write a OO PHP app wasn’t the greatest experience and that is directly related to the deficiencies of the language. Here are a few things I think that the PHP group should do in the next version of the language to make it a more viable, competitive programming language.

Get Rid of Old Stuff

One of the first things that needs to be done to clean up PHP is to get rid of all of the duplicate functions and old libraries that continue to hang around from PHP 4 and below. For example, there are currently two different libraries for connecting to MySQL databases plus the PHP data objects library that also supports MySQL. There is no need for three separate ways to connect to the same database. The language is also riddled with functions that do the exact same thing. For example the die() function and the exit() perform the same action. The documentation even says that they are same. There is no reason to keep both of them around. PHP needs to clean up all of the redundant functions in the language and focus on making the core functions better.

Add Real Namespace Support

PHP is adding namespace support in the upcoming version 5.3. Unfortunately, rather than use a normal, sensible delimiter that many other languages use, such as the period (.) or double colon (::), the PHP group has decided to use the backslash (\), most commonly known as the directory separator in MS Windows. If you combine that with any sort of auto-loading, your asking for confusion. The developers need to wake up, admit their wrong, and overload one of their reserved characters to give us some proper namespace support.

Real Constructor and Function Overloading

While PHP 5 gave us much improved support for object oriented programming constructs, they dropped the ball in the area of polymorphism, especially constructor and function overloading. Its time to get rid of those stupid magic methods __get() and __set() and give developers real function overloading support. Storing all of your private instance variables in an array is not a clean, easy to read approach to storing data in objects.

Better Type Hinting Support

PHP is a dynamically typed language and I don’t mind that one bit. But even with a dynamically typed language, there still is a difference between a string and a boolean value. Type hinting goes a long way in making sure that the data you pass into a function is of the correct type but I think it needs a bit more to be truly useful. PHP needs to enable type hinting for the primitive types as well as custom object types and arrays.

Built in Documentation Support

This is sort of a want to have feature that I think all languages should have. I know that there are plug-ins and external programs that give you Javadoc like support (I use phpDocumentor) but having it built in would make it so much easier to generate documentation. Its not a deal breaker but it would be great to have.

Single Extension Repository

One of the great parts about PHP is the large number of high quality plugins and modules that you can download and instantly expand the PHP language to support all sorts of technologies and systems. The problem is that they are housing in two different extension repositories: PECL and PEAR. While they use the same package structure there really isn’t any reason that I can tell to have two. To me it just creates confusion for newcomers and inexperienced developers. Lets drop the separate repositories and and create one uniform repository to house all of those great extensions.

So that is my short list on things that need to be fixed in PHP for it to continue to compete against languages like Java, C# and Python. Feel free to disagree and comment below. If you have a suggestion for other features that should be added/changed/removed, let me know. I welcome a good discussion. 🙂