[ruby-core:75513] [Ruby trunk Feature#9992] Access Modifiers (Internal Interfaces)

Issue #9992 has been updated by Daniel Ferreira.


Hi J旦rg, thank you very much for your interesting questions.

This is a subject for a wider discussion and your questions come in the right direction in my opinion.

My base view is the following example:

Fred wants to create a gem called `foo`.
Fred knows that he wants two methods on the interface:

~~~ ruby
Foo.bar
Foo.baz
~~~

This is all Fred aims to implement as the public interface of the `foo` gem for version v1.0.0.

Both `Foo.bar` and `Foo.baz` expose complex internals which Fred would like to keep isolated from outside the gem `Foo` namespace.

With time these internals will have an improved architecture with different *modules*, *classes*, *methods*, etc.

By using *internal* in the internal public methods Fred is confident that there is no broken backwards compatibility since no one can use the methods outside the gem namespace.

An internal method behaves:
1. Like a *public* method inside `Foo` namespace.
2. Like a *private* method outside `Foo` namespace.

So this is the logic behind the proposed implementation.

Now if Waldo does: 

~~~ ruby
Bar = Foo
~~~

Shall `Bar` be treated as `Foo` or not?

What we should not allow is something like:

~~~ ruby
module Foo
  class Bar
     def baz
         puts 1
     end
     internal :baz
  end
end

::Foo::Bar.new.baz    => error: internal method being called outside ::Foo namespace
~~~

For your presented challenges I would open the discussion to the wider community.
What are the possibilities and challenges we would face in order to implement the proposed `internal` access modifier?

I hope we can make it happen!
It will give us development freedom and architecture control.

---

**Note:**

I can understand we may get a degradation on performance by using `internal`.
Maybe we could use a flag to trigger it like we do for verbose.
With the flag off `internal` would behave just like `public`.
It would be a flag to increase levels of integrity in the code that we could use with different levels in dev, uat or production environments.
Maybe the extra flag would deserve  a separate proposal by its own but makes sense to present it in this context as well in my point of view.
We have debug, verbose and warning level flags.
Why not a new (architecture integrity/performance) flag?


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

* Author: Daniel Ferreira
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
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/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>