Nikita Ivanov is a founder and CEO if GridGain Systems – developer of one of the most innovative real time big data platform in the world. I have almost 20 years of experience in software development, a vision and pragmatic view of where development technology is going, and high quality standards in software engineering and entrepreneurship. Nikita is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Realities of Dynamic Typing: ActionScript

  • submit to reddit
I keep finding sometimes funny and sometimes troubling examples of what dynamic typing looks like in the “wild”. When I say in the “wild” I mean outside of cutesy one-liners and simple code snippets.

This time example comes from Adobe, developer of Flex and ActionScript programming RIA language for their flash runtime. This interface represents a simple Ajax-style callback for an asynchronous operation (full source code):

* This interface provides the contract for any service
* that needs to respond to remote or asynchronous calls.
public interface IResponder
* This method is called by a service when the return value
* has been received.
* While data is typed as Object, it is often
* (but not always) an
function result(data:Object):void;

* This method is called by a service when an error has been received.
* While info is typed as Object it is often
* (but not always) an
function fault(info:Object):void;

Now, looks innocent isn’t. But look carefully into the comments… Let me put in bold the offending logic there:

While info is typed as Object it is often (but not always) an...

Now, is it not great :) I don’t know what prevented Adobe to have a strongly typed contract here - backward compatibility or the case of premature design for extension.

Proponents of this style will argue the following:

  • The developer almost always knows what type to expect so the manual cast or dynamic method call is fine and usually safe
  • You should always write unit tests to test for the expected type

Again, I don’t know what is more absurd is the fact that you now need to write unit tests for the compiler logic (how else I should say that?) or the fact that you, the developer, is expected now to remember what types to use where… (and don’t forget to keep your comments in the code up to date with expected type information – or else!). And, of course, you have no idea what exceptions this code should through in case of any errors occurred in the callback logic itself.

Let me give you a counter example from GridGain. Here is the method signature from Grid interface that allows you to execute the grid task having the class of that task (it will be auto-deployed if it wasn’t deployed already):

public <T, R> GridTaskFuture<R> execute(Class<? extends GridTask<T, R>> taskCls, @Nullable T arg) 
throws GridException;

This signature provides wells of type safety with just a few extra characters in the signature saving your potentially hundreds of lines in unit testing and headaches of crashing application in runtime. Here are the contracts that are automatically enforced by the compiler and supported by type-safe refactoring:

  • Grid task expects two parameters of types <T> and <R> - type of the task’s argument and type of the task’s result value
  • Method execute(…) returns task future that will contain result value of type <R>
  • execute(…) method accepts execution argument of type <T>
  • execute(…) method accepts any subclass of GridTask<T, R> interface
  • Method execute() throw GridException to indicate error conditions and the called must provide handling logic
  • Parameter arg is nullable.

To understand the benefits of this approach try to imagine amount of unit tests and comments you will have to write to maintain the same type invariant… Strongly typed approach truly saves massive amount of work and time. Think about it…


Published at DZone with permission of Nikita Ivanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Collin Fagan replied on Wed, 2008/05/21 - 9:34am

I completely agree. Dynamic typing is all about "What can I get away with?" instead of "What does this really do?".

Jess Holle replied on Fri, 2008/05/23 - 6:35am

I concur 100%.  Dynamic typing would seem to be all about "how fast can I hack something?"

Having to write tests to do what a compiler should do is a waste of time. Liftweb claims to require 40% fewer tests than RoR due soely to this factor.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.