From: "alanwu (Alan Wu)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:106968] [Ruby master Bug#18435] Calling `protected` on ancestor method changes result of `instance_methods(false)`
Date: Wed, 05 Jan 2022 01:23:17 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-95796.20220105012317.39299@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18435.20211226142230.39299@ruby-lang.org
Issue #18435 has been updated by alanwu (Alan Wu).
I agree this is a confusing part of the API surface. This ticket reminds me of
the discussion from [Bug #16106].
Consider the following setup:
```ruby
class Parent
def foo; end
end
class Child < Parent
protected :foo
end
p Child.instance_method(:foo).owner # => Parent
```
`Module#instance_methods` (plural) only returns public and protected methods,
but `Module#instance_method` (singular) doesn't filter based on visibility.
Also, as Jeremy pointed out in [ruby-core:106839]
`Child.protected_instance_methods(false)` gives `[:foo]`, but
`Child.instance_method(:foo).protected?` gives `false` surprisingly.
So currently, `Module#protected_instance_methods` and similar APIs can provide
more information than `Module#instance_method`. APIs with plural names can
observe the effects of using `Child.protected(:foo)`.
An important question is whether `Module#protected` and other visibility change
APIs semantically define new methods when used in a subclass. If not, the
particular wording for relevant APIs cover the current behavior:
> Module#protected: ... With arguments, sets the named methods to have
> protected visibility ...
>
> UnboundedMethod#owner: Returns the class or module that *defines* the method.
> ...
The wording for `Module#instance_method` is unclear as to what should happen
when there is a visibility difference:
> Module#instance_method: Returns an +UnboundMethod+ representing the given
> instance method in _mod_.
I think Jeremy's [PR] makes it a rule that using visibility change methods in
subclasses semantically define new methods, but it opens up some design issues
I posted as a [comment] on GitHub. I don't think it should be merged as a
simple bug fix since it's a breaking change to APIs that are fairly fundamental
to the language. I do agree that the addition of `public?` and friends have
made how `Module#instance_method` behaves with respect to visibility change
APIs more surprising.
I think it's worth mentioning in docs that `Module#instance_method{s,}` are
very different despite having names that imply a relationship.
[PR]: https://github.com/ruby/ruby/pull/5356
[comment]: https://github.com/ruby/ruby/pull/5356#issuecomment-1005298809
----------------------------------------
Bug #18435: Calling `protected` on ancestor method changes result of `instance_methods(false)`
https://bugs.ruby-lang.org/issues/18435#change-95796
* Author: ufuk (Ufuk Kayserilioglu)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin20]
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
As documented `instance_methods(false)` works as follows:
```ruby
module A
def method1() end
end
class B
include A
def method2() end
end
p B.instance_methods(false) #=> [:method2]
```
However, calling `protected` on the method defined by `A`, unexpectedly changes the result of `instance_methods(false)` on `B`, even though the owner of the method is still `A`:
```ruby
module A
def method1() end
end
class B
include A
protected :method1
def method2() end
end
p B.instance_methods(false) #=> [:method1, :method2]
p B.instance_method(:method1).owner #=> A
```
In contrast, calling `private` or `public` on the same method does not cause any changes on the result of `B.instance_methods(false)`.
This feels like a bug in the implementation of `instance_methods(false)`, but, if it is by design, it should at least be documented on `Module#instance_methods`.
This reproduction script gives the same output all the way from Ruby 2.0 up to Ruby-HEAD:
https://wandbox.org/permlink/LqbXMBTYxURRZmDz
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2022-01-05 1:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-26 14:22 [ruby-core:106828] [Ruby master Bug#18435] Calling `protected` on ancestor method changes result of `instance_methods(false)` ufuk (Ufuk Kayserilioglu)
2021-12-26 21:09 ` [ruby-core:106829] " jeremyevans0 (Jeremy Evans)
2021-12-27 12:34 ` [ruby-core:106835] " ufuk (Ufuk Kayserilioglu)
2021-12-27 16:23 ` [ruby-core:106839] " jeremyevans0 (Jeremy Evans)
2021-12-27 19:28 ` [ruby-core:106842] " jeremyevans0 (Jeremy Evans)
2022-01-05 1:23 ` alanwu (Alan Wu) [this message]
2022-01-07 17:46 ` [ruby-core:107003] " Eregon (Benoit Daloze)
2022-01-14 0:56 ` [ruby-core:107107] " jeremyevans0 (Jeremy Evans)
2022-06-03 6:54 ` [ruby-core:108765] " matz (Yukihiro Matsumoto)
2022-06-09 10:23 ` [ruby-core:108833] " Eregon (Benoit Daloze)
2022-08-10 20:32 ` [ruby-core:109471] " jeremyevans0 (Jeremy Evans)
2022-08-13 3:27 ` [ruby-core:109477] " nagachika (Tomoyuki Chikanaga)
2022-08-13 3:31 ` [ruby-core:109478] " jeremyevans0 (Jeremy Evans)
2022-08-15 10:56 ` [ruby-core:109479] " Eregon (Benoit Daloze)
2022-08-15 11:11 ` [ruby-core:109483] " Eregon (Benoit Daloze)
2022-08-15 13:08 ` [ruby-core:109484] " Eregon (Benoit Daloze)
2022-08-18 9:24 ` [ruby-core:109538] " Eregon (Benoit Daloze)
2022-08-18 9:27 ` [ruby-core:109539] " Eregon (Benoit Daloze)
2022-08-20 12:30 ` [ruby-core:109593] " Eregon (Benoit Daloze)
2022-08-20 12:38 ` [ruby-core:109595] " Eregon (Benoit Daloze)
2022-09-03 6:06 ` [ruby-core:109827] " nagachika (Tomoyuki Chikanaga)
2022-09-29 13:52 ` [ruby-core:110148] " Eregon (Benoit Daloze)
2022-10-01 6:35 ` [ruby-core:110157] " nagachika (Tomoyuki Chikanaga)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-95796.20220105012317.39299@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).