Inconsistent behavior of interface inclusion
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 2.2k
- Forks
- 256
- Avg merge
- 6d 17h
- Merged PRs (30d)
- 37
Description
Summary: When including two interfaces with a method of the same name in each, an error is thrown; when including an interface that includes them both, the last definition included is used instead. Seems inconsistent.
Example:
interface _Foo
def a_method: () -> String
end
interface _Bar
def a_method: () -> Integer
end
interface _FooBar
include _Foo
include _Bar
end
Let's include _Foo and _Bar:
class FooBar
include _Foo
include _Bar
end
and try to find out what its definition is: rbs method FooBar a_method.
An error is thrown:
in `block (4 levels) in build_instance': ./sig/file.rbs:16:2...16:14: Duplicated method definition: ::FooBar#a_method (RBS::DuplicatedInterfaceMethodDefinitionError)
Now let's include _FooBar, which includes both _Foo and _Bar:
class FooBar
include _FooBar
end
Execute the same command: rbs method FooBar a_method and get a different output:
::FooBar#a_method
defined_in: ::_Bar
implementation: ::FooBar
accessibility: public
types:
() -> ::Integer
So that's a case of inconsistent behavior. Since there's a whole separate class of errors dedicated to duplication of interface methods, I would assume this case of nested inclusion is not handled properly?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the example in sig/file.rbs and run the rbs method FooBar a_method command for both direct and nested interface inclusion. Trace the entry point used by that command to compare duplicate-method handling, then add focused coverage for the two cases and verify their behavior is consistent with the intended interface rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100