On Oct 30, 2013, at 12:54 PM, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:

> David, I agree with you, and actually, I'd be already happy if "class" =
created the modules on the fly, but it can't without breaking =
compatibility, specially because it's not possible to know if the =
parents would be modules or classes...

Currently, using `module Foo::Bar` will raise NameError if Foo is not =
yet defined, so how would it break backwards compatibility if the =
behavior were changed to create all undefined parents as modules?  You =
might still end up with as error later if something else tried to create =
class Foo, so some cases would not benefit from this (just get a =
different error at a different point), but it would simplify the syntax =
for cases where Foo really is a module.

On a semi-related note, I find it mildly frustrating that all openings =
of a class requires specifying the same superclass.  Sometimes I just =
want to add a constant or simple method to a class, so it would be nice =
to be able to re-open that class without having to explicitly specify =
the same superclasses every time.  It would be nice if the following =
were allowed:

class Foo < Bar; end # class Foo extends Bar
class Foo; end       # class Foo still extends Bar

...and...

class Foo; end       # class Foo has Object as a "stand-in" superclass=20=

class Foo < Bar; end # class Foo replaces Bar as its "official" =
superclass

...and...

Of course, specifying conflicting explicit superclasses would still be =
an error.

class Foo < Object; end # class Foo has Object as its "official" =
superclass
class Foo < Bar; end    # error, inconsistent explicit superclass

Dave