-
Notifications
You must be signed in to change notification settings - Fork 437
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rename Type.Parameter to Type.Argument, part 2
Summary: **This diff** This diff is the second half of renaming `Type.Parameter` to `Type.Argument` (see below for stack description); at this point the type is renamed but I'm trying to rename all functions and variables that are really talking about type *arguments* rather than *parameters*. It is tricker for two reasons: - lots of code talking about "parameters" is referring to callable parameters, which still exist in `Type.t` - the concept of a type parameter *does* have meaning, and some downstream use cases (starting with `ClassHierarchy`) really do mean "type parameters" in their name As a result, the rename is best-effort and I tried *not* to rename anything that's actually about either callable parameters or type constructor type parameters. **This stack of 2 diffs** The `Type.t` data in OCaml primarily represents a (possibly propagated through analysis) type *annotation*. It does not represent in any meaningful sense a type *constructor*, which is a concept that has no direct representation in Pyre but is basically mapped to a "class" in the current architecture. In terms of modern vocabulary, typically we talk about "parameters" versus "arguments"; apparently there's also a mostly older vocabulary that calls these "formal parameters" vs "parameters", but "paramters" / "arguments" is already the vocabulary that Pyre uses for function calls and type instantiations have the same distinction. But because a `Type.t` loosely corresponds to an *annotation*, the values inside of a `Type.Parametric` form are not actually "parameters", they are "arguments". I have two motivations for making this change now: - We're starting to have discussions about the architecture of how Pyre represents types, and it's confusing to distinguish argument vs parameter in discussions (which is important, if you cannot name a concept then you can't really have a conversation about it) and yet have the code use the wrong name. If the fix is easy, why not fix the code? - In order to improve our handling of type constructors (for now, generic classes) when supporting PEP 695, we will probably need a cleaner notion of type *parameters*, which means I want that name to be available so that we have the option of using it in a refactor. - for existing generics, the type *parameters* will be extracted from the type *arguments* of the "generic base class" - but for PEP 695 classes this will not be the case, the type parameters will be explicitly marked as they are in most other languages. This is part of why confusing the two concepts is such a problem for 695. Reviewed By: migeed-z Differential Revision: D61548861 fbshipit-source-id: a0f655c0791327ca6686e4a41ee18940575f03c5
- Loading branch information
1 parent
bc8270b
commit 357943f
Showing
37 changed files
with
705 additions
and
725 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.