Skip to content

Consider flipping peek_output_buffer() naming convention in next major release #30

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

Open
2 of 3 tasks
HadrienG2 opened this issue Jun 21, 2024 · 2 comments
Open
2 of 3 tasks

Comments

@HadrienG2
Copy link
Owner

HadrienG2 commented Jun 21, 2024

As discussed in #28 , in an ideal world, peek_output_buffer() would be called output_buffer(), and output_buffer() would be called output_buffer_mut(). And the input_buffer() API would work similarly. But that's a breaking API change, so ideally it would be done gradually.

  • First, publish a minor release that adds input_buffer_mut() and output_buffer_mut() methods and throws a deprecation warning when calling input_buffer() or output_buffer() (which are now aliases to these methods), with a warning that their semantics are going to change to read-only in the future.
  • Next, a few months to a year later, publish a major release which changes input_buffer() and output_buffer() to read-only access, removes the deprecation warning, and deprecates the peek_output_buffer() method.
  • Finally, a few months to a year later, publish another major release which removes the peek_output_buffer() method.
This was referenced Jan 23, 2025
@HadrienG2
Copy link
Owner Author

The first step (add _mut accessors and deprecate current non-mut accessor names with mutable access) has been taken in v8.1.0 on February 2, 2025.

In the next major release, I'll take the second step of flipping the non-mut accessors to read-only access (which will complete the migration for the producer side) and deprecating peek_output_buffer().

@HadrienG2
Copy link
Owner Author

The second step (making non-mut accessors read-only) has been taken in PR #47, which is destined to eventually become v9.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant