BT

Your opinion matters! Please fill in the InfoQ Survey!

Try to get the best of your Statically Typed Language

| by Sadek Drobi Follow 0 Followers on Apr 11, 2008. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Echoing at a discussion on dynamic vs. static languages, Debasish Ghosh raises the issue of using dynamic type-checking while programming with static languages. He recalls the common generalization of Greenspun's 10th Law: "any sufficiently complicated program in a statically-typechecked language contains an ad-hoc, informally-specified bug-ridden slow implementation of a dynamically-checked language."  

Ghosh believes that this is not necessarily so today. He argues that Java generics, e.g. Guice and EasyMock, allow avoiding workarounds necessary to enforce runtime type checking: 

Using Java generics, these frameworks allow compile time type checking for cases which would earlier have to be implemented using a slow and bug ridden simulation of runtime type checking. Guice and EasyMock stand out as two frameworks I have been using that have used the power of generics to implement extraordinary typesafety. […] 

Have a look at this piece of code, which binds an implementation

SpecialServiceImpl to the interface Service using Guice Binder

public class MyModule implements Module {
public void configure(Binder binder) {
        binder.bind(Service.class)
                     .to(SpecialServiceImpl.class)
                     .in(Scopes.SINGLETON);
}
}”

Even though “it may seem that the "implements" relationship between Service and SpecialServiceImpl is done during runtime”, all type checking is actually done during compile time:

A peek at the source code of Guice reveals that BinderImpl.bind() returns BindingBuilderImpl .. 

public BindingBuilderImpl bind(Class clazz) {
return bind(Key.get(clazz));

and BindingBuilderImpl.to() takes as input Class - the bound on the wild card enforces the above "implements" relationship as part of compile time type checking of the arguments .. 

public ScopedBindingBuilder to(Classextends T> implementation) {
return to(TypeLiteral.get(implementation));
}

Debasish Ghosh advocates for using this kind of solutions rather than trying to achieve dynamic type checking. Not only does it allow avoiding the Greenspun's10th Law but it optimizes the advantages of static typing because it guarantees strong type-safety: 

When you are programming in a statically typed language, use appropriate language features to make most of your type checking at compile time. This way, before you hit the run button, you can be assured that your code is well-formed within the bounds of the type system. And you have the power of easier refactoring and cleaner evolution of your codebase.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT