2 votes Go team publishes draft design proposals for a new read-only filesystem interface and a standard way to embed files into Go binaries Posted August 1 by spit-evil-olive-tips Tags: programming languages, go, operating systems, filesystems https://lwn.net/SubscriberLink/827215/09e920175bcc83b1/ Link information This data is scraped automatically and may be incorrect. Title Go filesystems and file embedding Word count 2555 words 1 comment Collapse replies Expand all Comments sorted by most votes newest first order posted relevance OK skybrian August 1 Link Optional interfaces making the decorator pattern infeasible seems like a flaw, but it seems like it's tough to fix. You either specify the entire interface (in all its complexity) or you don't.... Optional interfaces making the decorator pattern infeasible seems like a flaw, but it seems like it's tough to fix. You either specify the entire interface (in all its complexity) or you don't. Fully specifying it means that no change is backward-compatible, because it will break decorators. Not fully specifying it means it's hard to wrap. I guess an intermediate solution is to make the interface modular, so you wrap can wrap some subinterfaces but not others, and move the rapidly-changing stuff to its own sub-interface that hopefully doesn't need to be wrapped. If filesystem methods don't support contexts and you can't wrap a filesystem to do something context-specific (like logging) then it seems like it gets pretty messy.