On Oct 30, 2013, at 2:55 PM, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:

> When I talk about conflicts, I'm worried about an existing =
MyModule::MyClass in the project.
>=20
> If you do "module MyModule::MyClass::InnerModule" without requiring =
the class first, it would create the MyClass constant as a module and =
then you would have different behavior depending on how you're requiring =
InnerModule.
>=20
> Currently, it won't create MyClass as a module on demand, but will =
raise an exception instead and the developer will be warned about the =
mistake.

Yes, currently this raises NameError (uninitialized constant).

> But if we change the behavior of "module" to make it create inexistent =
parent modules on demand it will then fail silently from current =
programmer expectation. This is what I refer to as backward =
incompatible.

If we change the behavior, then the implicit creation of module MyModule =
and module MyModule::MyClass and module MyModule::MyClass::InnerModule =
will "work", but then any subsequent attempt to create class =
MyModule::MyClass will fail loudly.  It would be equivalent to:

module MyModule; end
module MyModule::MyClass; end
module MyModule::MyClass::InnerModule; end
class MyModule::MyClass #=3D> raises TypeError: MyClass is not a class

So essentially it would be backwards compatible so long as it's not =
misused.  If it is misused, then it's not backwards incompatible (double =
negative) since you still get an exception, though it would be a =
different exception raised at a different point.

Dave