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

The _create method should be public #729

Open
4 of 6 tasks
corranwebster opened this issue Oct 10, 2020 · 3 comments
Open
4 of 6 tasks

The _create method should be public #729

corranwebster opened this issue Oct 10, 2020 · 3 comments
Labels
difficulty: easy Issues which don't need much/any context about the package. Feature type: refactoring Issues related to refactoring
Milestone

Comments

@corranwebster
Copy link
Contributor

corranwebster commented Oct 10, 2020

The base Widget._create method is nominally private, but in practice tends to get used as:

w = Widget(parent=parent)
w._create()

although a few widgets perform the _create() call as part of their __init__.

Two-phase creation has an advantage in that it permits programmatic configuration of the widget beyond what is passed in at class creation time before the underlying toolkit control is created.

This issue proposes that:

  • there is a public create method, which initially can be implemented to simple call _create (Add a create method for IWidget #735)
  • that calls to _create are changed to calls to create
  • that classes migrate the implementation of _create into create, and make _create call create
  • that _create is removed

Additionally:

  • any classes which call _create or (worse) _create_control in their __init__ be modified to not do that
  • classes in Tasks which match the new IWidget interface (such as ITaskPane) should be modified to inherit from IWidget and their implementations to inherit from Widget.
@corranwebster corranwebster added difficulty: easy Issues which don't need much/any context about the package. Feature type: refactoring Issues related to refactoring labels Oct 10, 2020
This was referenced Jul 13, 2021
@corranwebster
Copy link
Contributor Author

corranwebster commented Jul 13, 2021

Strategy for removing create calls from __init__:

  • initially:
    • add a keyword-only argument create which defaults to True initially (since create is a method name it will never conflict with a trait name)
    • if create is True then call the create method, but also issue a PendingDeprecationWarning
  • in the next a major release:
    • ignore the create argument other than indicate that it is deprecated if it is passed
  • at some later release, remove any handling for create (ideally, removing the entire __init__ method).

@corranwebster corranwebster added this to the Release 8.0 milestone Jul 13, 2021
@corranwebster
Copy link
Contributor Author

corranwebster commented Jul 13, 2021

I've added this to the 8.0 release - the next few steps in this should be done for that release, if time permits.

It will not be completed in the 8.0 release, however.

corranwebster added a commit that referenced this issue Mar 14, 2023
This carries out the next two steps of #729

- [x] replaces calls to `_create` with calls to `create`
- [x] that classes migrate the implementation of `_create` into
`create`, and make `_create` call `create`

as well as the next step in removing `create` calls from `__init__`
methods:

- [x] properly deprecate auto-create, but don't fail yet; push toward
removing `create` keyword argument.
@corranwebster
Copy link
Contributor Author

Incremental progress in the 8.0 release, the rest pushed to 9.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: easy Issues which don't need much/any context about the package. Feature type: refactoring Issues related to refactoring
Projects
None yet
Development

No branches or pull requests

1 participant