Potential type-safety issues on object parsing function in DXL I have inherited the maintenance of a DXL script (for IBM Doors).

In this, I came across various examples of stuff that make me scratch my head. Take this example:

int key = 3
print key


Running this in Doors, results in the expected output: 3.

However, in the documentation, we see that key is also the name of a function.

Object o
for o in numberCache do {
    // must cast the key command.
    int i = (int key numberCache)
    print i
}


While even the reference docs are full of examples declaring stuff like string key, Item key and so on, my concern is about safety.

What bad things I can run into, potentially, leaving the code I'm maintaining as is, knowing that it works, despite the fact it contains several functions using key as a variable name?

For instance, I'm really worried about this function right here:

void linkFindObjects(string value, Module m, string key_name, Skip objectList)
{   
    Object  o
    string  key, key2, key3
    bool match1 = false
    bool match2 = false
    bool match = false

    for o in m do {
        key = probeAttr_(o, key_name)       

        if(key == value)
        {   
            put (objectList, o, o)
        }
    }

}


My concern is that in DXL parenthesis are not mandatory: as you can see in the example, casting key(numberCache) can be simplified in key numberCache. When declaring the first three strings, the only thing preventing the whole code to blow up seems to be the comma. Please ignore for now the fact that the code declares a lot of unused stuff. It is as I got it.

Am I worrying too much?
Of course, it's bad mojo to use predefined key words as variable names, and yes, this might bring you into trouble. 

About "key": key is only defined for skip lists (perm: _x key (Skip)) and for the internal perm HttpHeaderEntryString_ key (). It is not possible to cast a Skip list to a string, the code Skip sk = create(); string s = "hello " sk "!" will not be valid, so there is almost no danger that the interpreter wants to make a string concatenation when you have the code xx = key sk, even when key is defined as a string variable. 

So, in this case, you are more or less safe.string key key2 key3 will give you a plain old syntax error that you can easily detect.