3 ms·

It mostly comes from the intentional design of open classes, thus the namespace organisation is fundamentally decoupled from the filesystem: any Ruby file has t

by lloeki 3y ago

It mostly comes from the intentional design of open classes, thus the namespace organisation is fundamentally decoupled from the filesystem: any Ruby file has to be able to contain any class/module, otherwise one can't add to an open class/module†! There are a bunch of issues about this upstream about this, e.g: https://bugs.ruby-lang.org/issues/14982 https://bugs.ruby-lang.org/issues/14982 My exploratory take on it: https://github.com/lloeki/package-ruby https://github.com/lloeki/package-ruby I'm currently drafting a proposal and planning to open another one, more focused on a specific aspect and a different angle, and thus with a couple of comparative PoCs that'll be a bit different from my above exploratory attempt. † ... via `class` and `module` keywords, as one could always include/extend/prepend or use `module_eval`/`class_eval`/`instance_eval`.

matheusmoreira 3y ago
At first glance that makes a lot of sense given Ruby's open classes and extreme dynamism. On closer examination though I conclude open classes are not mutually exclusive with a proper modules system. Ruby's classes are reified as normal objects. A module system manages names, symbols, references to those objects. To modify a class we just need its object, which name it comes from doesn't really matter. We'd be able to modify classes even if Ruby had a real modules system. All we need to do is get a reference to that class object, probably by importing it from somewhere into the current namespace. Ruby does exactly that already. Every class just happens to get stored as a constant of the Object class. So creating a class A just stores the new Class instance in ::Object::A which is totally weird when I think about it. And when programmers write A, Ruby looks up the constant in current scopes and eventually finds ::Object::A which contains the Class instance. A proper modules system would allow programmers to define where that object ends up or gets pulled from.
- lloeki 3y ago
  I was mostly outlining where it came from, as in, what is the original design. Doesn't mean it can't do other things. And actually it can, which is part of my initial proposal with the linked repo, and goes much more in depth in my pending, non-public draft.

by lloeki 3y ago

matheusmoreira 3y ago

At first glance that makes a lot of sense given Ruby's open classes and extreme dynamism. On closer examination though I conclude open classes are not mutually exclusive with a proper modules system. Ruby's classes are reified as normal objects. A module system manages names, symbols, references to those objects. To modify a class we just need its object, which name it comes from doesn't really matter. We'd be able to modify classes even if Ruby had a real modules system. All we need to do is get a reference to that class object, probably by importing it from somewhere into the current namespace. Ruby does exactly that already. Every class just happens to get stored as a constant of the Object class. So creating a class A just stores the new Class instance in ::Object::A which is totally weird when I think about it. And when programmers write A, Ruby looks up the constant in current scopes and eventually finds ::Object::A which contains the Class instance. A proper modules system would allow programmers to define where that object ends up or gets pulled from.

lloeki 3y ago
I was mostly outlining where it came from, as in, what is the original design. Doesn't mean it can't do other things. And actually it can, which is part of my initial proposal with the linked repo, and goes much more in depth in my pending, non-public draft.