Hi Nobuyoshi, The notion of Internal Interfaces is about being able to use the methods = identified as =91internal=92 only in the context of a given module and = all its subclasses and/or submodules. That way if we develop a new gem lets call it=20 'gem foo' We would be able to define an Internal Interface that would only be used = internally by gem foo classes and modules and by any other gem foo = extension like for instance 'gem foo-bar=92 Versioning of releases with this feature would be able to communicate in = a great more detailed to the users what nature of changes were made in = each release. We could identify: * Public Interface changes with broken backward compatibility - Critical = (current =91major') * Public Interface changes without backward compatibility - Major = (current 'minor=92) } order of priorities to be = discussed! * Internal Interface changes with broken backward compatibility - Minor = (currently doesn=92t exist) } order of priorities to be discussed! * Any other change - Bugs - Refactoring - Reengineering ( Internal Interface changes without backward = compatibility) - Tiny (currently =91patch=92) This would be very much useful to better use TDD (Test Drive = Development) best practices. I have much more to say and elaborate about this. My idea is to leverage ruby further in order to be proper for uses = inside the enterprise environment. I work for a company that has more then 300 developers working with ruby = and that is present in dozens of countries in the world. This feature would be very helpful to allow us to define better our = architecture. Ruby give us all the freedom but when you work with such a big number of = people it=92s good to have tools that allows you in a clear and = understandable way to define certain boundaries. Happy to reply to any doubts and discuss with you this thoughts and what = other alternatives may we have. Cheers Daniel On 28 Jun 2014, at 20:17, nobu / ruby-lang.org wrote: > Issue #9992 has been updated by Nobuyoshi Nakada. >=20 > Description updated >=20 > They don't seem to belong to same namespace. > Could you elaborate? >=20 > ---------------------------------------- > Feature #9992: Access Modifiers (Internal Interfaces) > https://bugs.ruby-lang.org/issues/9992#change-47437 >=20 > * Author: Daniel Ferreira > * Status: Open > * Priority: Normal > * Assignee:=20 > * Category:=20 > * Target version:=20 > ---------------------------------------- > Hi, >=20 > I=92m would like to discuss with you the concept of Internal = Interfaces. >=20 > Currently ruby offers three access modifiers choices to set methods = visibility: >=20 > - public > - protected > - private >=20 > Public methods define what we may call the Public Interface. > Private methods are private to the class and its subclasses. > Protected methods are public for the subclasses. >=20 > I would like to work with a new access modifier that would allow the = creation of Internal methods. >=20 > Internal methods would be object methods that could only be called = within the namespace. >=20 > Ex: >=20 > ~~~ruby > module Foo; end >=20 > class Foo::Bar > def baz=20 > puts =91baz=92 > end > internal :baz > end >=20 > class Foo::Qux > def baz > ::Foo::Bar.new.baz > end > end > ~~~ >=20 > Is this something that we can think about in a future implementation = of ruby? > An extra feature that would not break backward compatibility. >=20 > Cheers, > Daniel >=20 >=20 >=20 > --=20 > https://bugs.ruby-lang.org/