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

Replace on_trait_change decorators with observe #585

Merged
merged 39 commits into from
Apr 1, 2021

Conversation

aaronayres35
Copy link
Contributor

This PR replaces uses of the @on_trait_change decorator with the equivalent form using observe.

I made changes one file at a time and ran test suite / tested examples after each change. However, it is possible certain changed code is not under test.

@rahulporuri rahulporuri self-requested a review March 31, 2021 02:00
Copy link
Contributor

@rahulporuri rahulporuri left a comment

Choose a reason for hiding this comment

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

almost LGTM

chaco/barplot.py Outdated
@on_trait_change('line_color, line_width, fill_color, alpha')
def _attributes_changed(self):
@observe('line_color, line_width, fill_color, alpha')
def _attributes_changed(self, event):
Copy link
Contributor

Choose a reason for hiding this comment

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

i'm not a fan of the *_changed method name especially when it's not a trait change handler but i can't think of one better either.

Copy link
Contributor

Choose a reason for hiding this comment

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

In general, i've been told that the methods shouldn't be named based on what changed - rather, they should be named to convey what they are going to do.

Until we find a better name, maybe we can just call this _attributes_updated - which i've seen elsewhere in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

alternatively, we could rename it to _invalidate_and_redraw - if no such method already exists in the class heirarchy - because that's what the method does.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the base enable component class has an invalidate_and_redraw method (just no leading underscore, which also simply just calls self.invalidate_draw() and self.request_redraw()

@on_trait_change('color_mapper:updated')
def _color_mapper_updated(self):
@observe('color_mapper:updated')
def _color_mapper_updated(self, event):
Copy link
Contributor

Choose a reason for hiding this comment

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

same comment as above about updating method name.

@on_trait_change('edge_color, edge_width, edge_style, face_color, alpha')
def _attributes_changed(self):
@observe('edge_color, edge_width, edge_style, face_color, alpha')
def _attributes_changed(self, event):
Copy link
Contributor

Choose a reason for hiding this comment

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

same comment as above - about renaming this to _invalidate_and_redraw if such a method doesn't already exist in the class heirarchy

@aaronayres35
Copy link
Contributor Author

Okay I have gone through and done a bunch of renaming and also started to follow Corran's suggestion about using metadata and pulling the hook for invalidate_and_redraw up higher. I have pulled in into PlotComponent for now so that it could all be done in this PR. Eventually we may want to pull that even further up into Component in enable.

Now if a particular trait changing will require an invalidate and redraw, one can simply set the metadata requires_redraw=True in the trait definition.
Note I did not do this in all such cases here, because sometimes we are setting these things up on nested traits. eg all traits on a color mapper. But I imagine these objects could be used in other contexts and we dont really want to mess with trait definitions that don't belong to that particular object that wants invalidate_and_redraw called?
I am still a little unsure about this and would like to discuss a bit more.

Nonetheless, I believe this PR is close to being ready to push through

Copy link
Contributor

@rahulporuri rahulporuri left a comment

Choose a reason for hiding this comment

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

Mostly LGTM with a few comments -

  1. I would have preferred it if we made the request_redraw related changes in a separate PR - given that those changes are adding a new feature and are sort of unrelated to the scope of this PR.
  2. We need to document the fact that classes which inherit from PlotComponent can define traits with the metadata request_redraw if they want changes to the trait to trigger an invalidate and redraw.
  3. I'm trying to think of a different/better name than request_redraw but i can't come up with any at the moment. We want to be conscious of the choice because it will be part of the public API.

@@ -75,7 +75,7 @@ class BaseXYPlot(AbstractPlotRenderer):
orientation = Enum("h", "v")

#: Overall alpha value of the image. Ranges from 0.0 for transparent to 1.0
alpha = Range(0.0, 1.0, 1.0)
alpha = Range(0.0, 1.0, 1.0, requires_redraw=True)
Copy link
Contributor

Choose a reason for hiding this comment

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

This will now spill over into other classes which inherit from BaseXYPlot i.e. any subclass of BaseXYPlot will invalidate and redraw if the alpha value changes.. That might be the right behavior but we need to be conscious of the fact that we might be modifying behavior.

@aaronayres35
Copy link
Contributor Author

Mostly LGTM with a few comments -

  1. I would have preferred it if we made the request_redraw related changes in a separate PR - given that those changes are adding a new feature and are sort of unrelated to the scope of this PR.

Yeah you are right, my bad on that. I can still pull it out at this point if you prefer

  1. We need to document the fact that classes which inherit from PlotComponent can define traits with the metadata request_redraw if they want changes to the trait to trigger an invalidate and redraw.

That makes sense, I will add this

  1. I'm trying to think of a different/better name than request_redraw but i can't come up with any at the moment. We want to be conscious of the choice because it will be part of the public API.

I believe it is currently requires_redraw not request_redraw (perhaps request is better though 🤔 ). A longer winded but more specific alternative might be requires_redraw_on_change? I am not sure, naming things is hard.

@rahulporuri
Copy link
Contributor

Yeah you are right, my bad on that. I can still pull it out at this point if you prefer

No no lets not.

I believe it is currently requires_redraw not request_redraw (perhaps request is better though 🤔 ). A longer winded but more specific alternative might be requires_redraw_on_change? I am not sure, naming things is hard.

Let's go with requires_redraw for now. we can revisit this before the release and put it up for vote with the rest of the team/folks.

@aaronayres35 aaronayres35 merged commit a6911ee into master Apr 1, 2021
@rahulporuri rahulporuri deleted the replace-on_trait_change-decorators branch April 7, 2021 05:24
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.

2 participants