Object and Function Name Spaces

Share icon

I recently became aware that the name spaces of objects (waves, global variables, strings etc.) are somehow still shared with function names even when they are declared static and even inside independent modules. This was clear for normal functions, but I didn't realized the extend of the problem for static functions. I want to understand this better and check whether I need to take any action with my projects. Consider the following code:

Function Test()
    Print "Test1", WaveExists(thisIsATest1())
    Print "Test2", thisIsATest2()
End
 
static Function/WAVE thisIsATest1()
    return $""
End
 
static Function thisIsATest2()
    return 0
End

Igor does (obviously) complain when trying to do the following:

Make/O/D Test

Igor does not complain, when executing one of the following:

Make/O/D thisIaATest1
Make/O/D thisIaATest2

BUT, if you somehow change the code above and want to recompile it (or reload the experiment later), bad luck => you'll get an error. Putting these functions within a regular module or even an independent module will not help.

I wonder why Igor is fine with the overlapping names as long as the code is compiled first. In the worst case, the experiment works fine but then cannot be loaded properly anymore, because Igor realizes that there is a clash next time. Does this mean I have to rename all my static functions to very long and convoluted names to avoid any possible clash with user data? I have some particular short ones for convenience at the moment, but this seems rather dangerous, considering above issue. Is there any way to separate the name spaces? I guess free waves inside functions are fine since they are not global, or...?

Yes. I discovered this with a package from Tony (Baselines I think). I had a wave that was named the same as one of the procedures in his procedure file.

Does this mean I have to rename all my static functions to very long and convoluted names to avoid any possible clash with user data? 

Technically yes. Practically no, not in your life time. You could consider putting letter prefixes on the front of the possibly questionable function names, e.g. for my case ... Function JJW_SetTime should likely not conflict with a wave name that someone would select by specific choice (while Function SetTime may conflict at some point).

October 14, 2025 at 06:23 am - Permalink

I still feel like the compiler is over-zealous here.

If I have 

#pragma ModuleName = foo
 
static function foo(variable x)
    return x
end
 
static function bar(variable x)
    wave foo
    return foo(x)
end

I can execute this:

•make foo=0
•print foo(3), foo#foo(3), foo#bar(3)
  0  3  0

So function and wave coexist peacefully until I try to recompile. 

Admittedly it is a little confusing that the syntax coloring in function bar suggests that foo(x) refers to the function foo#foo, but it's interpreted as procglobal wave foo, as I would expect. Just like a wave reference overriding a built-in function.

A protected namespace should give you the freedom to use unobfuscated function names.

October 14, 2025 at 07:12 am - Permalink

The syntax coloring code doesn't know anything about waves/variables/strings/data folders, so it's just looking to see if a "word" is a built-in command, user-defined function, etc. In IP10 the coloring code is slightly more aware of its surroundings, so it can properly highlight keywords for an operation, but it still doesn't know anything about global objects.

October 14, 2025 at 08:48 am - Permalink

As Tony notes, the behavior is a bit strange, since apparently everything works fine until the compiler steps in. I was under the false impression that static function are safe, but I guess I'll have to go through my code and change things a bit.

October 14, 2025 at 07:44 pm - Permalink