IDL 8.4 - Sliced bread, step aside

For my money, there have been a handful of IDL releases that have had the greatest impact on my ability to produce efficient and flexible applications in my professional life, both in my 18+ years in the Custom Solutions Group and in my earlier incarnations as a science data analyst for various research projects.

• Version 1:  "You mean I don't have to spend hours writing Tektronix PLOT-10 FORTRAN programs to see my data?"  My remaining undergrad years flew by after that.
• Version 3.6: Cross-platform widget support and a GUI-oriented development environment
• Version 5.0. Object Graphics and object-oriented language syntax
• Version 6.4. The last of the releases largely shepherded by Ali Bahrami, former IDL product architect, provided much of the infrastructure for TCP/IP client and server applications we rely on.

IDL 8.4 has the potential to have a similar level of positive influence on the way I write code.  In particular the addition of built-in variable attributes and static methods will at the very least reduce the amount of code needed to perform the functionality I use regularly in IDL through functions such as SIZE, STRTRIM, and N_ELEMENTS.

 

Using other programming languages such as Python as a pattern, IDL_Variable types have been extended to have object-like behavior when certain syntax is encountered by the interpreter at run-time.

 

Some static methods and attributes act as more compact means to access existing functionality.  Some of these also offer improved performance relative to their procedural counterparts.

 

Others represent brand-new functionality that in previous releases required multiple IDL statements.  Don't overlook this wide selection of new static methods that expand functionality. For example, there's a very useful new static substitution method on string variables, ".Replace".

 

Though it's not called out explicitly, you can add your own static methods as well.

 

For example, to serialize an IDL variable's contents for transmission via HTTP, for example in an ENVI Services Engine task request parameter, we might compress the data and convert to a Base-64 encoding.

FUNCTION IDL_Variable::jp_Serialize, s
   COMPILE_OPT STATIC
   RETURN, IDL_Base64(ZLib_Compress(s))
END

 

IDL> b = BINDGEN(5,5)
IDL> r = b.jp_Serialize()
IDL> r
eJxiYGRiZmFlY+fg5OLm4eXjFxAUEhYRFROXAAAAAP//AwAKQQEt

 

In order to reconstruct the variable on the receiving end, the client will need the ASCII stream along with the data type code and the dimensions.  The latter two items can be retrieved via the variable attributes ".Typecode" and ".Dim".

 

IDL> b.typecode, b.dim
           1
           5           5

 

The deserialization static method is simply the inverse operation.

 

FUNCTION IDL_Variable::jp_Deserialize, s, TYPE=type, DIMENSIONS=dims
    COMPILE_OPT STATIC
    RETURN, ZLIB_Uncompress(IDL_Base64(s), TYPE=type, DIMENSIONS=dims)
END

 

IDL> r.jp_Deserialize(TYPE=1,DIMENSIONS=[5,5])
   0   1   2   3   4
   5   6   7   8   9
  10  11  12  13  14
  15  16  17  18  19
  20  21  22  23  24

 

For future compatibility it's important to provide a namespace for your IDL_Variable class extensions that have little potential to conflict with possible extensions by the IDL engineering team in the future.  In this example, I'm using a "jp_" prefix.

 

Given that the IDL_Variable class does not extend objects or structures, how would you consider implementing a serialization/deserialization mechanism for those data types?  For named structures and objects, it's entirely possible via proxy static class methods and temporary SAVE files.  This is an exercise left for the reader.  Or a topic for a future blog post!