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!