Feature #9992

Access Modifiers (Internal Interfaces)

Added by Daniel Ferreira about 1 year ago. Updated 12 months ago.

[ruby-core:63391]
Status:Open
Priority:Normal
Assignee:-

Description

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:

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

History

#1 Updated by Nobuyoshi Nakada about 1 year ago

  • Description updated (diff)

They don't seem to belong to same namespace.
Could you elaborate?

#2 Updated by Daniel Ferreira about 1 year ago

Hi Nobuyoshi,

The notion of Internal Interface is about being able to use the methods identified as internal only in the context of a given root module and all its subclasses and/or submodules. Lets call it: namespace full tree.

The namespace full tree in this context would integrate all constants of the tree defined by the namespace root and all its subnodes.

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 extension like for instance:

gem 'foo-bar'

We have this notion of Public and Internal interface when looking at an API (Application Public Interface) in Web Services.

Web Services expose to the users a given set of methods/actions making them Public.

The remaining of the architecture is internal to the infrastructure.

In ruby libraries/packages/gems every class is available to the user.

That makes development of libraries hard because a change to the public interface of a given class may have side effects.

We may need to create a major release just because we need to change some method in one of our classes that should not be used outside of the library context.

What I aim as an architect is to allow a better defined contract between developers and users.

Having the definition of an Internal Interface the architect will have greater freedom to develop the required functionalities.

The development process may be like this:

  1. Define Public Interface
  2. Release version 1.0 once that Public Interface is well defined and will hardly change.
  3. Reengineer the Internal Interface and add functionality to the Public Interface without breaking backwards compatibility.

This way dependencies between libraries will be much better understood.

Versioning of releases with this feature will be able to communicate in a greater detail to the users what nature of changes were made in each release.

We may then identify:

  • Major release

Third party libraries and/or applications might be broken.
Library extensions might be broken.

  • Public Interface changes with broken backward compatibility
  • Public Interface changes with backward compatibility

    • Minor release

Library extensions using internal interface features might be broken.

  • Internal Interface changes with broken backward compatibility
  • Internal Interface changes with impact on overall behaviour

    • Performance improvements
    • New core engine
      • Patch (Tiny) release

No side effects on extensions or third party libraries and/or applications.

  • Internal Interface changes with backward compatibility (new features for extensions)
  • Changes to private interface (private and protected methods)
  • Bugs
  • Refactoring
  • Unit test updates

With this feature the library development cycle will be much more linear.
Major releases will be in a much smaller number then nowadays.
We will get much more stable ecosystems.

My idea is to leverage ruby further in order to better fit the enterprise environment.

Happy to reply to any doubts and discuss with you this thoughts and what other alternatives may we have.

Cheers

Daniel

#3 Updated by Zachary Scott 12 months ago

I would suggest opening a feature request if you feel strongly about adding internal to Ruby.

See also: https://bugs.ruby-lang.org/projects/ruby/wiki/HowToRequestFeatures

#4 Updated by Zachary Scott 12 months ago

Ehh, sorry I must have missed #9992

Also available in: Atom PDF