-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement user-defined type guard method #1501
base: master
Are you sure you want to change the base?
Conversation
05bd3c7
to
1e9f080
Compare
def context_from(type_name) | ||
if type_name.namespace == RBS::Namespace.root | ||
[nil, type_name] | ||
else | ||
parent = context_from(type_name.namespace.to_type_name) | ||
[parent, type_name] | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not find such a helper method in Steep and RBS.
I'm not sure where the best place is.
d43291c
to
6821365
Compare
type = RBS::Parser.parse_type(type_name) | ||
raise "Unknown type: #{type_name}" unless type | ||
|
||
context = context_from(definition.type_name) | ||
type = type.map_type_name { factory.absolute_type_name(_1, context: context) or raise "Unknown type: #{_1}" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to handle errors on Interface::Builder? It seems there is no typing
object. So typing.add_error()
can't be used here.
6821365
to
8b39651
Compare
This implements the minimal version of user-defined type guard method. A user-defined type guard methos is a method defined by user that is able to guarantee the type of the objects (receiver or arguments). At present, Steep supports type guard methods provided by ruby-core (ex. `#is_a?`, `#nil?`, and so on). But we also have many kinds of user-defined methods that are able to check the type of the objects. Therefore user-defined type guard will help checking the type of these applications by narrowing types. This implementation uses an annotation to declare user-defined type guard method. ``` class Example < Integer %a{guard:self is Integer} def integer?: () -> bool end ``` For example, the above method `Example#integer?` is a user-defined type guard method that narrows the Example object itself to an Integer if the conditional branch passed. ``` example = Example.new if example.integer? example #=> Integer end ``` In this PR, the predicate of type guards only supports "self is TYPE" statement. I have a plan to extend it: * `%a{guard:self is arg}` * `%a{guard:self is_a arg}` * `%a{guard:self is TYPE_PARAM}` * `%a{guard:arg is TYPE}` Note: The compatibility of RBS syntax is the large reason of using annotations. I'm afraid that adding a new syntax to define it will bring breaking change to the RBS, and difficult to use it on common repository or generators (ex. gem_rbs_collection and rbs_rails).
8b39651
to
84f75ef
Compare
This implements the minimal version of user-defined type guard method. A user-defined type guard methos is a method defined by user that is able to guarantee the type of the objects (receiver or arguments).
At present, Steep supports type guard methods provided by ruby-core (ex.
#is_a?
,#nil?
, and so on). But we also have many kinds of user-defined methods that are able to check the type of the objects.Therefore user-defined type guard will help checking the type of these applications by narrowing types.
This implementation uses an annotation to declare user-defined type guard method.
For example, the following method
Example#integer?
is a user-defined type guard method that narrows the Example object itself to an Integer if the conditional branch passed.In this PR, the predicate of type guards only supports "self is TYPE" statement. I have a plan to extend it:
%a{guard:self is arg}
%a{guard:self is_a arg}
%a{guard:self is TYPE_PARAM}
%a{guard:arg is TYPE}
Note: The compatibility of RBS syntax is the large reason of using annotations. I'm afraid that adding a new syntax to define it will bring breaking change to the RBS, and difficult to use it on common repository or generators (ex. gem_rbs_collection and rbs_rails).
refs: