"TheEndless" wrote:
Out of curiosity, what is the concern with declaring them with a global scope, since they can still be referenced for use within a particular object's context?
"belltown" wrote:"TheEndless" wrote:
Out of curiosity, what is the concern with declaring them with a global scope, since they can still be referenced for use within a particular object's context?
In my case, it's so I can create a library that could potentially be used by many other source code files, and not have to worry about naming conflicts. I'm not trying to hide the functions from the caller, just ensure that they don't have the same names as anything that might be used elsewhere. I've run into problems, for example, in some of the Roku example code (e.g. the MRSS code) where I've tried to use some of their utility functions only to find that their names conflict with my own, or in one version of the MRSS template, names that conflicted with function names in other parts of their own code.
Expose you library functionality via Brightscript classes rather than global functions
* Use the Brightscript singleton pattern to make methods available via a function (named with your unique library identifier) at global scope.