From: grzesiek.bizon@... Date: 2018-05-17T11:24:17+00:00 Subject: [ruby-core:87132] [Ruby trunk Feature#14758] Add a first-class support for isolated bounded packages / modules / contexts Issue #14758 has been updated by grzesiek (Grzegorz Bizon). Thank you for your replies Daniel, Robert! > Also I only test the API. > I don't unit test internal modules or classes. I guess that this is usually a bad idea, but it depends on what you are using your tests for. When I have to develop a complex module I usually follow TDD because TDD is a design tool for me, not a testing tool per se. But I would like to avoid diving into discussions about TDD here. Daniel, internal modifiers are interesting, but I think this feature would not work for me. I would like to make isolation a default solution, I don't want to remember about specifying a modifier each time I create a constant. I think that package / context / boundary isolation would be mostly useful in case of complex modules, that consist of many internal constants. Robert, I agree with the comment about that this is against Ruby's philosophy of not restricting users. But then Encapsulation, one of the core principles of Object Oriented Paradigm would also be against Ruby's philosophy, is that correct? I personally believe that hiding complexity is not against Ruby principles. Programming in general is about building abstractions, and hiding complexity behind facades, and restricting access to internals is working in favor of a making code conceptually manageable, which should help a programmer. And this is probably top priority of Ruby language. > Why would you want to prevent others from accessing any part ofruby code? Is it a real problem? Does something break if others do? In all the explanations given, I have never read an explanation as to WHY it should be restricted exactly. "All non-trivial abstractions, to some degree, are leaky." People are going to use internal code of a module, because it is more simple than thinking about extending abstractions. Extending an abstraction involves thinking in terms of building intention-revealing interfaces and a good design, and this is much more complex than just leaking an abstraction. If would like to have a mechanism that will tell developers that in this particular case, this is not a good idea. But if they decide to do that anyway, there should certainly be away of doing that somehow. > Also note that ruby's core philosophy is to let people (ruby hackers) do what they want to. Sure, I'm not against doing that, but I would like to have a mechanism that will reveal my intention of hiding internal classes better. I'm not aware of any existing mechanism like this at the moment. > In big teams with very big projects ruby code can become unmanageable. That is one of the reasons big corporations still use JAVA very extensively. Putting barriers to bad practices helps a lot in this management. I've seen that as well. Ruby code can deteriorate quickly because there is no good way of hiding complexity. But please note that I'm not talking about creating barriers here, I'm talking about passing knowledge, and intention of an author of a module to people who are going to work on it in the future. I believe this makes things more simple in the end, instead of more complex, and is a win-win solution for everyone. ---------------------------------------- Feature #14758: Add a first-class support for isolated bounded packages / modules / contexts https://bugs.ruby-lang.org/issues/14758#change-72118 * Author: grzesiek (Grzegorz Bizon) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- While one of the core principles of Ruby is to extend the language in a way it is a most useful and convenient tool that a software developer can have in their toolbox, lack of a first-class isolation on module level can cause some serious problems when project grows beyond some size. This is especially visible in large projects, where most of the code lives in the `lib/` directory, and there are tens or hundreds of modules there. Ideally we would like to make these modules isolated and hide complexity behind facades. Currently it is not possible to isolate such modules, because a developer can still reach beyond boundary of a bounded context, and use `MyModule::InternalClass` directly. It is very difficult to enforce boundaries, currently it requires a lot of work to implement complex static analysis rules. Would it make sense to add support for first-class `package`, `context` or `boundary`, that would be a regular module but would not allow referencing inner constants from outside? ~~~ context MyModule class MyIsolatedClass # ... end def self.build MyIsolatedClass.new end end MyModule::MyIsolatedClass # raises context violation MyModule.build # => Returns an instance of MyModule::MyIsolatedClass ~~~ I'm pretty sure that I failed at finding similar feature proposal that has been already submitted, in that case sorry for that! Please let me know what do you think about that! Thanks in advance! <3 -- https://bugs.ruby-lang.org/ Unsubscribe: