From: David MacMahon <davidm@...>
Date: 2013-10-30T21:50:54-07:00
Subject: [ruby-core:58094] Re: [ruby-trunk - Feature #9064] Add support for	packages, like in Java


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.
> 
> 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.
> 
> 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 #=> 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