-
Notifications
You must be signed in to change notification settings - Fork 5
Improve names of ConstraintVariable
, etc.
#413
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
Comments
If the only change is a refactor from
Personally, I'd prefer not to use typedefs for renaming, especially since CLion doesn't search across them. And I prefer variable names whose lengths are correlated with both their scope and rarity. Here "medium" like "ConsideredPointer". But the biggest problem I see is the 2nd, that there are a lot of variables with names that reference the current type names. "PCV" becomes meaningless if its type is "ConstrainableObject". It's a bad variable name, but it's a lot more work to change everything like that. What's the proposal for dealing with variables whose names reference the current class names? |
You have some valid points. I think I think the issue of the typedefs is largely separable: we could inline them now, or we could rename them to shortened forms of the new names with the option to inline them later. At this point, I don't think I know enough to conclude either that I want to go ahead with the change as soon as I have time or that it will never be worthwhile to make this change, so I'm just going to leave this issue open. Further comments would be welcome. |
Uh oh!
There was an error while loading. Please reload this page.
I previously wrote:
(Addendum: My original proposal was
ConstrainableObject
, etc.;AnnotatableObject
was a new idea this morning. Then I realized that one way in whichConstrainableObject
is superior is that there are some things we annotate that don't have their own constraint variables, such as checked regions. There might be a compromise such asSolvableObject
, or maybe that's too unwieldy and we should go withConstrainableObject
.)John added:
I plan to work on this after our upcoming PR to Microsoft. I'm starting this issue thread so we can discuss the new names we want before I start a draft PR; it seems awkward to start the draft PR and then discuss the names there.The text was updated successfully, but these errors were encountered: