Making a library... Is it possible to force the programmers that will use it to use a qualified name to access the internal variables?

    Hi all,

    As in the subject states, I am writing a code library. And, in order to keep things tidy and avoid variable, procedure, function names... collisions with whatever any operator could have declared outside the library...

    Is there any way to add a forced qualifier?

    I could insert all variables inside a RECORD, but that would leave procedures and functions out of this, plus I could not initialize the variables at declaration time.

    I could set a prefix, but it would be super that the programmers who would use it would need to add the module name in front of the functions and variables names.

    Is enforcing that possible?

    Thank you in advance.

    Hi Lemster.

    Using a PERS variable in a library module is direct in RAPID. Just write the name of the variable and that's it.

    Imagine I declare a variable named "i" that is pers.

    Then imagine that my library is loaded in a robot that has another "i" variable somewhere else.

    This can cause all sorts of problems.

    I need the variable "i" to be global, but at the same time I want to prevent the mentioned problem.

    It would be better if I could enforce the programmers that want to use my library to write the name of the module before the variable name, something like:

    library.i := 10;

    That would remove the ambiguous usage of i and would not make it necessary to write a_very_large_and_obscure_name_i := 10; to "avoid" that problem.

    But I can't use records because I can't initialize them at declaration time.

    the long and obscure prefix could help, but it's not a guarantee.

    I would prefer being able to enforce the scope/qualifier before the usage of the library variables and/or procedures / functions.

    Hope it's clearer now.

    Thanks for your time.

    Using long and descriptive names is the only way I'm aware of to try to avoid the namespace collision issue.

    Also, any time you can declare a variable inside a PROC or FUNC, instead of at the Module level, also helps, since a variable declared this way has its scope limited to that routine, rather than being global or local. Also, using LOCAL on as many variables as possible at the Module level also helps reduce the opportunities for collisions.

    I also do things like special prefixes for variables. For example, any PROC-level variable would be declared with a name starting with "_", and received arguments start with an "FI_" or "FO_" for incoming or outgoing (INOUT) arguments. Avoiding common names like "Counter" or "X" helps too.

    Still, at the end of the day, all this only mitigates the collision risks, since you simply won't have control over what other libraries get added to the robot alongside yours. And if whomever wrote those libraries was careless with their variable naming, well....

Advertising from our partners