Skip to content
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

- unify locations for normal and endless method definition #718

Merged
merged 1 commit into from Jul 6, 2020

Conversation

marcandre
Copy link
Contributor

This way one can ask loc.end or loc.assignment of all method definitions

@marcandre
Copy link
Contributor Author

Note: this keeps locations untouched for Module

Copy link
Collaborator

@iliabylich iliabylich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one small note

loc(end_t))
Source::Map::MethodDefinition.new(loc(keyword_t),
loc(operator_t), loc(name_t),
loc(end_t), nil, nil)
end

def endless_definition_map(keyword_t, operator_t, name_t, assignment_t, body_e)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's rename this method to method_definition_map

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. But we'll need to keep an alias for compatibility, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

endless_definition_map is (was) used only in ruby28.y that is still in development. I think it's ok to rename without any aliases

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry, I thought you wanted definition_map => method_definition_map.

Would you like to rename endless_definition_map => method_definition_map and that this is used for standard and endless method definitions?

My PR uses definition_map for standard methods, and endless_definition_map for endless ones. This way definition_map remains as a valid API and the implementation is updated, but maybe there's a better way to go.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(seems it would be confusing if standard methods used definition_map and endless ones used method_definition_map)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, I think it's better to keep it as is.

EDIT: just got a notification from GH that you reverted it. Yes, let's keep it as is, otherwise it sounds like it handles all method definitions. 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I had misunderstood your comment (although you clearly made it on the def endless_definition_map, I should have paid more attention)

@marcandre marcandre force-pushed the endless_loc branch 2 times, most recently from ca95288 to 6826c1a Compare July 6, 2020 21:19
Copy link
Collaborator

@iliabylich iliabylich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@iliabylich iliabylich changed the title Unify locations for method and endless method definitions [#716] - unify locations for normal and endless method definition Jul 6, 2020
@iliabylich iliabylich merged commit 07ab97e into whitequark:master Jul 6, 2020
@@ -1856,6 +1856,7 @@ def test_def
%q{def foo; end},
%q{~~~ keyword
| ~~~ name
|! assignment
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iliabylich I'm glad you suggested we introduce this notation, didn't think I'd use it so soon 🙇‍♂️

@iliabylich
Copy link
Collaborator

@marcandre Do you need a release?

@marcandre
Copy link
Contributor Author

marcandre commented Jul 6, 2020

Not really, but maybe @palkan would like one (he pointed this out)

@marcandre marcandre deleted the endless_loc branch July 6, 2020 21:28
@palkan
Copy link
Contributor

palkan commented Jul 7, 2020

No rush, I'm good, thanks) Just want to make sure the tests pass against master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants