Issue #9992 has been updated by Daniel Ferreira.


 Hi Nobuyoshi,
 
 The notion of Internal Interfaces is about being able to use the methods identified as °∆internal°« 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 
 
 '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 extensionlike for instance 'gem foo-bar°«
 
 Versioning of releases with this feature would be able to communicate in agreat 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 °∆major')
 * Public Interface changes without backward compatibility - Major (current'minor°«)                       } order of priorities to be discussed!
 * Internal Interface changes with broken backward compatibility - Minor (currently doesn°«t exist)  } order of priorities to be discussed!
 * Any other change
  - Bugs
  - Refactoring
  - Reengineering ( Internal Interface changes without backward compatibility) - Tiny (currently °∆patch°«)
 
 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°«s 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.
 > 
 > Description updated
 > 
 > They don't seem to belong to same namespace.
 > Could you elaborate?
 > 
 > ----------------------------------------
 > Feature #9992: Access Modifiers (Internal Interfaces)
 > https://bugs.ruby-lang.org/issues/9992#change-47437
 > 
 > * Author: Daniel Ferreira
 > * Status: Open
 > * Priority: Normal
 > * Assignee: 
 > * Category: 
 > * Target version: 
 > ----------------------------------------
 > Hi,
 > 
 > I°«m would like to discuss with you the concept of Internal Interfaces.
 > 
 > Currently ruby offers three access modifiers choices to set methods visibility:
 > 
 > - public
 > - protected
 > - private
 > 
 > 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.
 > 
 > I would like to work with a new access modifier that would allow the creation of Internal methods.
 > 
 > Internal methods would be object methods that could only be called within the namespace.
 > 
 > Ex:
 > 
 > ~~~ruby
 > module Foo; end
 > 
 > class Foo::Bar
 >  def baz 
 >     puts °∆baz°«
 >  end
 >  internal :baz
 > end
 > 
 > class Foo::Qux
 >  def baz
 >     ::Foo::Bar.new.baz
 >  end
 > end
 > ~~~
 > 
 > Is this something that we can think about in a future implementation of ruby?
 > An extra feature that would not break backward compatibility.
 > 
 > Cheers,
 > Daniel
 > 
 > 
 > 
 > -- 
 > https://bugs.ruby-lang.org/

----------------------------------------
Feature #9992: Access Modifiers (Internal Interfaces)
https://bugs.ruby-lang.org/issues/9992#change-47438

* Author: Daniel Ferreira
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Hi,
 
I°«m would like to discuss with you the concept of Internal Interfaces.
 
Currently ruby offers three access modifiers choices to set methods visibility:

- public
- protected
- private

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.
 
I would like to work with a new access modifier that would allow the creation of Internal methods.
 
Internal methods would be object methods that could only be called within the namespace.
 
Ex:

~~~ruby
module Foo; end

class Foo::Bar
  def baz 
     puts °∆baz°«
  end
  internal :baz
end

class Foo::Qux
  def baz
     ::Foo::Bar.new.baz
  end
end
~~~

Is this something that we can think about in a future implementation of ruby?
An extra feature that would not break backward compatibility.
 
Cheers,
Daniel



-- 
https://bugs.ruby-lang.org/