4 ms·

I would like to second (or _third_) this opinion. I've been working with Ruby for 20 years, and I've not needed something like this. This feels like adding a l

I would like to second (or _third_) this opinion. I've been working with Ruby for 20 years, and I've not needed something like this. This feels like adding a lot of complexity for little practical benefit. The trade-off feels off. I don't think this is worth the additional complexity.

usrbinenv 1y ago
I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
- ezekg 1y ago
  > Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem. Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing. I'd like to hear of a real use case for namespaces that existing conventions don't already solve.
  - usrbinenv 1y ago
    Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
    - ezekg 1y ago
      What's the difference between FooBar::Record and ns1::Record? Nothing, except the latter pushes encapsulation onto the user. This is not the Ruby ethos.
      - usrbinenv 1y ago
        On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
      - ljm 1y ago
        Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new. And why would you bother doing that when it would be a breaking change?
    - vidarh 1y ago
      If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>". Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing: module MyGroup include Module1 include Module2 ... end In other words, wrapping them doesn't remove your ability to use short non-namespaced names. Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby: def wrap_load(path) = class_eval(File.read(path), path) module Test # some_file.rb will act as-if defined within Test wrap_load("./some_file.rb") end You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies. Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.
fellowniusmonk 1y ago
I think byroot got it exactly right with: >First, I'm not convinced by the motivations: > >Avoiding name conflicts between libraries: Applications can require two different libraries safely which use the same module name. > >Is this a problem that happens on a regular basis? I believe Ruby has a pretty well established convention for libraries to expose a single module with a name that correspond to their gem name. I really don't think we want to make it easier for newbies to alter gem naming conventions and run multiple versions of a gem within the same project, this sounds like a genuine nightmare to me. I've found from jumping in to fix broken and crippled rails projects for startups that the fuckup surface area is already high enough.
werdnapk 1y ago
I've been working with Ruby full time for pretty much 20+ years as well and there's many parts of it I've never used, although when I need one of it's many features, I love that it's there. I just used a refinement for example last month for the first time to help clean up some code that I didn't want polluting top level classes everywhere.

usrbinenv 1y ago

I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.

ezekg 1y ago
> Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem. Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing. I'd like to hear of a real use case for namespaces that existing conventions don't already solve.
- usrbinenv 1y ago
  Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
  - ezekg 1y ago
    What's the difference between FooBar::Record and ns1::Record? Nothing, except the latter pushes encapsulation onto the user. This is not the Ruby ethos.
    - usrbinenv 1y ago
      On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
    - ljm 1y ago
      Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new. And why would you bother doing that when it would be a breaking change?
  - vidarh 1y ago
    If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>". Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing: module MyGroup include Module1 include Module2 ... end In other words, wrapping them doesn't remove your ability to use short non-namespaced names. Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby: def wrap_load(path) = class_eval(File.read(path), path) module Test # some_file.rb will act as-if defined within Test wrap_load("./some_file.rb") end You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies. Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.

fellowniusmonk 1y ago

I think byroot got it exactly right with: >First, I'm not convinced by the motivations: > >Avoiding name conflicts between libraries: Applications can require two different libraries safely which use the same module name. > >Is this a problem that happens on a regular basis? I believe Ruby has a pretty well established convention for libraries to expose a single module with a name that correspond to their gem name. I really don't think we want to make it easier for newbies to alter gem naming conventions and run multiple versions of a gem within the same project, this sounds like a genuine nightmare to me. I've found from jumping in to fix broken and crippled rails projects for startups that the fuckup surface area is already high enough.

werdnapk 1y ago

I've been working with Ruby full time for pretty much 20+ years as well and there's many parts of it I've never used, although when I need one of it's many features, I love that it's there. I just used a refinement for example last month for the first time to help clean up some code that I didn't want polluting top level classes everywhere.