Conversation
|
|
||
| // Reset. | ||
| source.readString() | ||
| val _ = source.readString() |
There was a problem hiding this comment.
Just thinking out loud: in reality, is this a frequent case, do we need a method like skipAll()?
There was a problem hiding this comment.
I'll check if anyone uses something like that. For now, replaced it with source.transferTo(discardingSink())
| val sink = Buffer() | ||
| sink.writeString('b'.repeat(Segment.SIZE - 10)) // limit = size - 10 | ||
| sink.readString((Segment.SIZE - 20).toLong()) // pos = size = 20 | ||
| val _ = sink.readString((Segment.SIZE - 20).toLong()) // pos = size = 20 |
There was a problem hiding this comment.
Can it be replaced by skip(n)?
It's not entirely obvious why to read a string in such a place and then ignore its value.
There was a problem hiding this comment.
Done, thanks for pointing to it!
| } | ||
| parts.asReversed().forEach { | ||
| fs.mkdirSync(it) | ||
| val _ = fs.mkdirSync(it) |
There was a problem hiding this comment.
Can we briefly write why we ignore it? Without knowledge of the JS API, it looked dangerous.
There was a problem hiding this comment.
It returns undefined in all cases but when recursive (there is no such parameter in our declaration) is true (it returns the first created path then).
I changed the return type to Unit for now.
TBD: it's unclear if unsafe ops should be ignorable
2 participants
A few functions were annotated as ignorable, they could be categorized in a following way:
Base64.encodeToAppendableBuffer.transferFromBuffer.writeSink.transferFromSource.transferToFor the first group, everything is trivial: functions returns a receiver, and unless a users wants chaining calls, it's fine to ignore the result.
The number of consumed bytes should not be ignorable in general, but
Sink.transferFrom/Source.transferToconsumes everything from the source and unless it is necessary to know how many bytes were there, it is safe to ignore the result. For comparison, functions likereadAtMostToconsumes a variable number of bytes and also indicate an exhaustion by retuning a negative value, thus their results have to be checked.There is a third group of functions that I considered annotating as functions with ignorable results, but abstained from doing that: unsafe operations. All those operations return the number of read/written bytes, but in all use cases within the library, that value could be safely ignored, because the actual number of transferred bytes is tracked elsewhere. I think it is safe to leave them non-ignorable for now, and reconsider this decision later.