5 ms·

I am surprised that it doesn't have public interfaces with context. Network file system could use the same interfaces + timeout settings.

• icholy 6y ago
  There was discussion about this. One approach would be to tie the entire fs.FS instance to a context. Something akin to `http.Request.WithContext`.
  • jeffbee 6y ago
    How would that be helpful? A context deadline is a fixed point in time. You really want the context (and its deadline) to be specified at the operation scope, not at the file or at the entire filesystem level. And you might have a deadline on a read but be willing to wait forever for a close, so you don't really want the deadline to be attached to the file handle, either.
    • q3k 6y ago
      As long as something like `(f FS) WithContext(ctx context.Context) FS` exists and has overwrite/replace semantics, then that could be used to do more narrow scoping of particular requests, no? Ie. `fs.WithContext(ctxT1).Read()` vs `fs.WithContext(ctxT2).Close()`.
    • andrewstuart2 6y ago
      It definitely wouldn't need to be at the top level. Remember, this is an interface, so func (f SomeConcreteFS) WithContext(ctx context.Context) fs.FS could hold a reference to the underlying filesystem and call appropriate read deadlines, timeouts, etc.
      • sudhirj 6y ago
        And the draft specifically mentions that those methods are the minimum interface - a library that supports contexts could always do this either way.
• infogulch 6y ago
  Oh god no, this draft is actually pretty good, don't ruin it by infecting it with context. Context is the worst library in Go: it's a pile of hacks to get cancellation and goroutine-local storage by manually passing new heap-allocated objects through every function interface in every library between low-level IO up to task management. It infects everything, obliterating separation of concerns making even libraries that should have nothing at all do do with timeouts include code for it. And it includes an untyped key-value store implemented as a linked-list of pairs (!!!!), because why not? If you can't tell, I don't like context. I've said before [0] I really hope that Go 2 comes up with an actual solution to the cancellation and task-local storage problems and deprecates context. Some comments in that thread pointed to alternatives that looked pretty decent, I wonder what state they're in these days. [0]: https://news.ycombinator.com/item?id=18561884 https://news.ycombinator.com/item?id=18561884
  • solatic 6y ago
    Everything old is new again. This challenge is basically why monads exist, because the monad allows you to cleanly separate between the state in which the algorithm is running and the algorithm itself. Reminds me of: https://philipnilsson.github.io/Badness10k/posts/2017-05-07-escaping-hell-with-monads.html https://philipnilsson.github.io/Badness10k/posts/2017-05-07-... I wonder what poor abstraction the Go authors will come up with instead?
    • philosopher1234 6y ago
      How would you apply monads to solve the context problem? Hard for me to imagine what that would look like
      • dllthomas 6y ago
        I think what they have in mind is a Reader monad. newtype Reader r a = Reader { runReader :: r -> a } instance Monad (Reader r) where pure x = Reader (\ _ -> x) m >>= f = Reader (\ r -> runReader (f (runReader m r)) r) which allows us to define: getContext :: Reader r r getContext = Reader (\ r -> r) and which spares us threading the context manually. I don't think that's such a big deal, so long as there's only one thing we're threading. In some languages, we can be generic over "contexts which provide the thing I want, whether they do other things or not", which is sometimes a much bigger win.
• joshuak 6y ago
  I am not a fan of the context pattern either, however one can support it without need to explicitly define that support. var fs fs.Fs fs = somefs.New() fs = contextfs.New(context.TODO(), fs) fs is now an fs with an imbedded context.
• nikon 6y ago
  Accept interfaces, return structs?