Groovy #6 – Curious case of pedantic ignorance

If you know C, its easy to pickup C++.
If you know C++, its easy to pickup Java.
If you know Java, its easy to pickup Groovy.

We have all heard this. Yeah its easy to pickup something. But how easy it is to fit into it? Despite Java being touted as oo language, programmers still write a lot of procedural-type code in it. It is easy to ‘learn’ a language, but much more not easy to assimilate the philosophy of the language or familiarize with its idiosyncracies. I’m still somewhat finding difficulty in fitting into the philosophy of C#/.Net, where the Rate of Entropy (ie the time taken for the code to get into a disorderly or unorganized state) is way lower than that of Java.

When you realize that Groovy treats configuration files as yet another Groovy script, the concept of .properties is thrown out of the window. Along with that key=value pair, the .xml configs are also given a boot. Groovy allows a more compact, more predictable, less verbose, and a much more powerful way of handling configurations.

Consider the following snippet:

//Configuration.groovy
Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

//Person.groovy
class Person {
def config = new ConfigSlurper().parse(Eye)

boolean allowedEyeColor(def color) { color in config.Eye.colors }
}

//Test.groovy
Person p = new Person()
assert true == p.allowedEyeColor('black')

Ok, assuming that this is all the code, what is the most glaring mistake here?

a) In Person, parsing Eye is incorrect
b) Code will not work because allowedEyeColor is not a public method
c) Assert does not fail, the programmer is cheating
d) Assert should not have failed, the groovy compiler is cheating

If you had already spotted the bug, good for you. But you get bonus points if you say that Configuration.groovy is not unit tested :-)

Now lets add a unit test case to directly test the Eye configuration and see the value of Eye.colors:

def config = new ConfigSlurper().parse(Eye)
assert Eye.colors.size() == 5
//Result: assert fails!

The problem had me scratching my head for a few minutes, until I realized that the Orwellian theory applies to programming languages as well – All languages are equal. Some are more equal than others.

Literally more equal, yes.

The Configuration.groovy has the following line:

Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

Perfectly normal for the Java-tinted eyes.

But in Groovy, the above code is actually declaring a closure. In order to make it a “property”, it has to be declared like this:

Eye {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

Now, this is actually a config dsl, and Eye.colors can be accessed as expected.

But in the closure case, it has to be accessed like a method:

assert config.Eye().colors.size() == 5

The equals sign had creeped into the code while typing. Call it a habit, reflex or a case of pedantic ignorance.

About these ads

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 138 other followers

%d bloggers like this: