Except that as the example I gave showed, it is fairly trivial to wrap the bufio.Writer into a WriteCloser that retains that reference and performs the pass-through Close as expected. So if you have a situation that needs a WriteCloser, you can manage that. Meanwhile, the bufio classes provide valuable functionality to Writers and Readers, whether or not they have a Close function, at the cost of a simple requirement to call Flush after writes finish.
The current implementation *is* the more general one. So perhaps what would be better would be to add a bufio.WriteCloser that requires a WriteCloser to wrap, so that we don't have to implement one of our own in those cases. Howard On Wednesday, May 22, 2019 at 8:02:34 AM UTC-5, Robert Engels wrote: > > The more I think about this, the more I believe that this is a horrible > situation that breaks all rules of encapsulation. This requires the creator > to maintain references to the underlying Writer. It also requires the > creator to be the sole decider of when the Writer is closed, or the creator > must pass the concrete class to subordinates so they can close, or the > subordinates must do type casting. > > The bufio.Writer is badly broken and should be changed to declare Close > and pass this to the contained Writer if it is a WriterCloser. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/da01596f-d958-46f0-9bca-18b768e49a35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
