I don’t believe your example is correct. In order for a current wrapper to call
Flush on Close on the bufio.Writer the Close would need to be defined on the
Wrapper struct so there would be no name collision.
I think it is best to see the proposal before commenting. I plan on addressing
any co
I have to say that I must prefer APIs that do not take arbitrary advantage
of dynamically discovered methods. It makes things less clear, and adding a
wrapper to flush and then close the underlying writer is not hard. In fact
the idiom for doing so is probably the reason why it's not feasible to ad
The very fact that you downvote a proposal without reading it says a lot.
> On May 22, 2019, at 8:21 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Wed, May 22, 2019 at 3:15 PM Ian Lance Taylor wrote:
>
>>> The bufio.Writer is badly broken and should be changed to declare Close and
>>> pass t
Now that’s a good idea ! Hopefully sometime today. :)
> On May 22, 2019, at 8:15 AM, Ian Lance Taylor wrote:
>
>> On Wed, May 22, 2019 at 9:02 AM Robert Engels wrote:
>>
>> The more I think about this, the more I believe that this is a horrible
>> situation that breaks all rules of encapsula
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
On Wed, May 22, 2019 at 3:15 PM Ian Lance Taylor wrote:
> > 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.
>
> What to open a proposal for that? https://golang.org/s/proposal.
As I cannot vote on propos
On Wed, May 22, 2019 at 9:02 AM 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 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 mu
That’s a good case of dynamic type checking and good documentation
> On May 21, 2019, at 5:20 PM, roger peppe wrote:
>
> Probably it's not a Closer because that would imply that Close would close
> its underlying writer too, but then it would need to take a WriteCloser which
> would make it le
Probably it's not a Closer because that would imply that Close would close
its underlying writer too, but then it would need to take a WriteCloser
which would make it less general.
On Tue, 21 May 2019, 19:02 Robert Engels, wrote:
> That’s what I was saying, I incorrectly thought that the Writer
That’s what I was saying, I incorrectly thought that the Writer was a
WriterCloser.
Seems it should be with a noop if the contained Writer is not a WriterCloser.
This would be pretty much how every other platform does buffered IO.
> On May 21, 2019, at 11:19 AM, howardcs...@gmail.com wrote:
>
Excuse me if I am misunderstanding something - but it certainly looks to me
like you are not at any point closing the bufio.Writer (because it is not a
WriteCloser and does not support Close function). That is why you need to
flush it! What you are closing is the underlying file/stream/WriteClos
Sorry, per docs, the client should call the Flush method to guarantee all data
has been forwarded to the underlying io.Writer.
Not sure why the Write doesn’t implement Closer. That’s fairly non standard way
of doing buffered io...
> On May 21, 2019, at 8:42 AM, Subramanian Sridharan
> wrote:
I don't think so.
When I close the file and don't explicitly flush:
package main
import (
"bufio"
"fmt"
"io"
"os"
)
func main() {
sourceFilename := "MozillaFirefox-66.0.5-741.4.x86_64.rpm"
sourcef, err := os.Open(sourceFilename)
if err != nil {
fmt.Println("Error while opening source file:", er
I don't think so.
Closing file without flushing:
package main
import (
"bufio"
"fmt"
"io"
"os"
)
func main() {
sourceFilename := "MozillaFirefox-66.0.5-741.4.x86_64.rpm"
sourcef, err := os.Open(sourceFilename)
if err != nil {
fmt.Println("Error while opening source f
You do not need to flush if you call close. Close will flush. There is some
other bug in your code I believe.
> On May 21, 2019, at 3:01 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Tue, May 21, 2019 at 9:44 AM wrote:
>>
>> Usually though, you do not need to buffer the input or output at a
On Tue, May 21, 2019 at 9:44 AM wrote:
> Usually though, you do not need to buffer the input or output at all.
If I/O is performed in chunks comparable in size to what
bufio.{Reader,Writer} uses then ok. When I/O is done in small chunks,
then using bufio should improve performance.
The question
Hello,
Indeed, you need to flush the bufio.Writer for the remaining data to be
sent accross.
Usually though, you do not need to buffer the input or output at all.
In which case, the code is straight forward:
https://play.golang.org/p/F1tMKdsapyX
If you do need to buffer though, I would do somet
18 matches
Mail list logo
