Issue #14758 has been updated by dsferreira (Daniel Ferreira).


Hi Robert,

I agree that we should not change current ruby behaviour.
I see the proposal as an extra functionality not a behaviour change.

Regarding allowing ruby hackers to do all they want:
* Ruby allows developers to find their way to accomplish what they want. 100% freedom is good in my point of view.
* You mentioned `Object#send` as an example
* `private_method` vs `public_method` is another example
* For sure we can find a way to force "internal interface" access for ruby hackery joy. :-)

The problem with enterprise code is that sometimes it is hard to do proper code reviews and force best practices.
I have that experience.
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.

In the mean time my advise would be to try to implement a better code review process if possible. 
(Lots of times it is not)
Maybe requiring two reviewers instead of just one?
Teams, specially when they are new to ruby tend to do all kinds of architecture mistakes.
Why? Because ruby just allows it.
And when the project managers are only concerned with delivery times that is what you get.
Once you need more than the standard Rails MVC files structure things will tend to be done in the wild land.
Enter `lib/` dir and all you will find is caos.
Do you use service classes?
SOLID patterns?
It may help as well...

> shevegen (Robert A. Heiler) wrote:
>
> Also in the linked issue:

Can you please comment on the specific issue ticket?
I just linked it because I think it's related to the subject in question here.

----------------------------------------
Feature #14758: Add a first-class support for isolated bounded packages / modules / contexts
https://bugs.ruby-lang.org/issues/14758#change-72006

* 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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>