[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: 'name conflict for module' with Compat-5.1
- From: "Andre Carregal" <carregal@...>
- Date: Mon, 30 May 2005 17:45:38 -0300
> I'll try to explain my setup:
> I want tables (containing namespaces) as follows:
> Tests.Component1 -- Contains all the tests for Component1
May I suggest a different setup?
and then use only
whenever you need to test feature1 from component1. The file could be only
... some more code to implement tests for feature 1.
Notice that you can have more than one FeatureN file using the same module
namespace (although local functions won't be visible among the different
> When there exists a global variable with the name "Component1", the
> of the tests will fail if the variable does not reference a table.
That is the part that I'm still puzzled about. If you require
"Tests.Component1.Feature1" before anything, there shouldn't be any global
"Component1", but even if there is one such global, there will be no name
clash, since the module is supposed to be referenced by the global "Tests",
> I don't know beforehand which global variables will exist. I can probably
> this to make it work, but that will not make the issue go away.
I have to agree that sometimes it is impossible to prevent name clashing,
but usually a tool like what yours seems to be can be loaded before the user
scripts that will use it. So the name clashing is more easily avoidable (as
long as your users agree to skip the use of "Tests" or you accept to name
your module something else that they agree to not use).
> To summarise: It is possible to either prevent a library from loading or
> loading it into unexpected tables by declaring global variables with this
> implementation of compat.
I have to insist that apparently that is not the issue here, using the above
namespace scheme should make things easier for you and your users, no?