Open st0012 opened 6 years ago
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.
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.
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)
I'm personally fine with any solution.
The crucial concept is that it's made clear that under the stated conditions:
send
, to private methodit'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).
Will implement this in version 0.2.0
_
prefix instead ofprivate
keyword. Andprotect
won't be support.send
to call private methods