RE: 'name conflict for module' with Compat-5.1

["Andre Carregal" <carregal@...>]

> I'll try to explain my setup:
> 
> I want tables (containing namespaces) as follows:
> 
> 	Tests
> 	Tests.Component1 -- Contains all the tests for Component1

May I suggest a different setup?

What about

/Tests
  /Component1
    Feature1.lua

and then use only

require "Tests.Component1.Feature1"

whenever you need to test feature1 from component1. The file could be only

module "Tests.Component1"
... 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
files).

> When there exists a global variable with the name "Component1", the
loading
> 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",
not "Component1".

> I don't know beforehand which global variables will exist. I can probably
restructure
> 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?

Andre

<<attachment: winmail.dat>>