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

Allow components which are not "leaf" children in the class hierarchy #2021

Closed
angela97lin opened this issue Mar 23, 2021 · 5 comments
Closed
Labels
bug Issues tracking problems with existing features.

Comments

@angela97lin
Copy link
Contributor

In working on #1989, @freddyaboulton suggested that we make TargetImputer a subclass of SimpleImputer. Unfortunately, when looking for viable components in _get_subclasses, _get_subclasses will only collect classes that are at the very bottom of the hierarchy. For example:

ComponentBase --> Transformer --> SimpleImputer # will only grab SimpleImputer

The issue is, if we subclass SimpleImputer, we will have access to TargetImputer, but SimpleImputer will no longer be found by EvalML as a useable component:

ComponentBase --> Transformer --> SimpleImputer --> TargetImputer 
# will only grab TargetImputer, SimpleImputer is no longer a leaf

I believe the original intent is to not grab classes that are not useful (ex: Transformer), but this is a problem if we want to build upon useful components to create new ones.

Original comment here: #1989 (comment)

@chukarsten
Copy link
Collaborator

Options:
1.) Have the TargetImputer use the SimpleImputer.
2.) Don't define TargetImputer component, but instead apply the SimpleImputer to the target.
3.) Delete _get_subclasses() in favor of static list of components. (preferred)
4.) Make _get_subclasses() smarter.

Next step: schedule a discussion to decide how to go about doing this.

@freddyaboulton
Copy link
Contributor

freddyaboulton commented Mar 25, 2021

My opinion is that we shouldn't change anything unless we want to make inheritance of non base classes a more common pattern in our codebase. We currently don't do that so building a system to allow for that seems low priority to me.

This issue isn't blocking the target imputer or any short-term work we have ahead of us and the current system for identifying subclasses "works". If we really want 3 then that's another story hehe and I'd be down to hear arguments for it but I don't think there's a need to do it.

And if we wanted to leverage the SimpleImputer in the TargetImputer in the future we can use composition over inheritance, which I think is what option 1 is referring to.

@angela97lin
Copy link
Contributor Author

angela97lin commented Mar 25, 2021

Agreed with @freddyaboulton here, also worth noting that we defined _get_subclasses() in the first place because keeping track of a static list of components was a bit tedious / frustrating as we were adding more and more components. If we go for 3, it might make more sense to keep _get_subclasses() but also keep a list of "exceptions" such as the SimpleImputer / TargetImputer case, so that they're included, but other components such as the Transformer are still excluded.

Also okay with the idea of some composition-esque technique if that gets the job done.

@freddyaboulton
Copy link
Contributor

@angela97lin Do you think we can close this? I think we agree that we don't need to make changes to _get_subclasses to enable development of the TargetImputer/other components.

@angela97lin
Copy link
Contributor Author

@freddyaboulton Sure, we haven't really made inheritance of non base classes a more common pattern in our codebase. Perhaps we can reopen and revisit when/if we actually have a use case again :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues tracking problems with existing features.
Projects
None yet
Development

No branches or pull requests

3 participants