5221 Rate this article:
No rating

The Case For Static Methods

Dain Cilke

A new feature introduced in IDL 8.3 is the ability to create static methods on IDL objects. For those new to the world of Object Orientated programming, static methods are essentially a normal IDL function, except the function is attached to an object.  Let's take a look at a simple object definition:

function STATICEXAMPLE::doit, x

  compile_opt idl2

 

  return, x/2

end

 

pro STATICEXAMPLE__define

  compile_opt idl2

 

  self = { staticexample, $

           inherits IDL_OBJECT, $

           _count: 0b $  ; "unused" member variable

         }

end

In this example, our object has a function DOIT which doesn't actually depend on any member variables or other functions defined by our object. Traditionally, to call this method you would have to do the following:

obj = StaticExample()

obj.doit(2)

However, since DOIT doesn't actually depend on the state of the object or use methods defined on the object, it makes sense to mark DOIT as a static function to give it greater usability. We can do this by adding the static flag to the DOIT compile_opt:

function STATICEXAMPLE::doit, x

  compile_opt idl2, static

By marking the method as static, I can now reference the method in a single call:

StaticExample.doit(2)

Or if you have a STATICEXAMPLE object already:

obj.doit(2)

Note: It is best to avoid calling static methods this way.  It is a lot easier to read your code if you don't have to double check every method to see if it is static or not.

" OK, but what benefit does marking a function as static give me?"

1.       The ability to group functionality into a single object. 

For example, say you have two sets of function to read and process different file formats: ff1_Read(), ff1_Process(), ff2_Read(), ff2_Process(). I can use static methods to group functionality into meaningful objects. In this case, I would choose to group my methods by functionality to create READ and PROCESS objects. So my calls would now be: Read.ff1(), Read.ff2(), Process.ff1(), Process.ff2().  This, in turn, leads to...

2.       Content assist! 

By converting your functions into static methods you can use content assist to help find that function call. Now, when working in the workbench, I can press CTRL+Space on my Read or Process objects and find all the file formats which I can open or process. 

3.       Avoid naming conflicts. 

When IDL compiles a function, it uses the code of the first function which matches the name of the compiled function. As such, if you have a function called Colortable and IDL releases a new function called Colortable, one set of functionality will be unaccessable depending on the ordering of your PATH (this has probably happened to you, and we are sorry for the confusion it causes). However, by wrapping your functionality under a static method, the chance of a namespace collision greatly reduces and leads us to...

4.       Libraries!

If you have a library (or even a bunch of useful functions) and you want to give to your coworker, with static methods you now have a dedicated object to contain all of your functions. So, instead of having an ugly tag hanging off the front of your functions (i.e. MyAwesomeCode_MyAwesomeFunction()) you can have a pretty object (i.e. MyAwesomeCode.MyAwesomeFunction()). Plus, it means your objects benefit from content assist, not having to worry about naming conflicts, pretty method names, and overall making your code more readable.

 

Pitfalls:

When using static methods there are a couple of things to be aware of. Static methods are not normal methods on objects.  They are not aware of any other methods or member variables.

 

Cheers!

Please login or register to post comments.