Private method support

[st0012]

• As @hachi8833 suggested, we're going to support private method using _ prefix instead of private keyword. And
• protect won't be support.
• Users can override private methods
• Users can't use send to call private methods

[64kramsystem]

protect won't be support.

can you elaborate a bit on the private Goby visibility? will it have the exact same specification as Ruby?

using the exact same specification would, for example, disallow calling private methods of an instance of a given class, from another instance of the same class.

this is fine, although I think it should be designed very carefully. protected access level is in fact designed, in Ruby, to allow the behavior above, although, at the same time, Ruby has a very different (much more liberal) idea of public/private compared to, say, Java.

[hachi8833]

According to https://twitter.com/yukihiro_matz/status/180090910451834881, Matz feels that protected is redundant and says that he would not have adopted it if he could have. https://twitter.com/yukihiro_matz/status/180087810823438337 says that the keyword protected was added after adopting private, and it made developers from Java/C++ pretty confused. Considering this, protected feature looks unnecessary for Goby.

[hachi8833]

Personally, prohibiting the overriding ancestor classes's private _ methods is preferable for me: if descendant classes would unexpectedly overrides the ancestor's private _ methods, it would cause unexpected behaviors. Instead, unrestricted send can be a last resort to access any methods including private _ methods.

Using private _ is very easy and I expect this would promote appropriate protection on developer's codes. In other words, private _ might increase the chances of unexpected overriding.

Using send is rather intentional for developers and I hope this is not so easy to be exploited. (Longer method name like force_send or send_message might be better to mitigate the exploitation)

Of course I respect @st0012's final decision 😄

FYI: Ruby's specification for private is actually under influence of Smalltalk and just an indication that the method is for private use and not recommended for direct calling, according to https://twitter.com/yukihiro_matz/status/180083650413596672. (Of course send can go beyond the restriction)

[64kramsystem]

I'm personally fine with any solution.

The crucial concept is that it's made clear that under the stated conditions:

• using the Ruby semantics of private method accessibility
• no protected method accessibility
• no calls, via send, to private method

it's acceptable that the following code is impossible to run:

class Sphere
  def bigger_than?(other)
    volume_in_internal_measure_unit > other.volume_in_internal_measure_unit
  end

  # following is private method
  def volume_in_internal_measure_unit
    some_calculation + some_constant
  end
end

this is acceptable, it's just a design choice to keep in mind. Ruby, for example, tends to be more "public" in terms of methods accessibility, than Java (this example of private method call is very frequent in Java).

[st0012]

Will implement this in version 0.2.0