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/