3 ms·

Unhelpful abstractions

• mmarx 11y ago
  > Specifically, now every caller to this function has to pass in a mode value, even if the file exists, even if they don’t really care and are happy with a default file mode. Wouldn't this be solved by allowing for optional arguments (which go doesn't seem to support)? Also, why not just _explicitly_ set the file mode, even if the file still exists (as otherwise it would fail anyways)?
  • tyingq 11y ago
    Probably worth mentioning that mode will be ANDed with the current umask, so _explicitly_ setting the file mode requires a little more work.
    • mmarx 11y ago
      But this is also true if the file does not exist, and the could would then fail anyways.
• junke 11y ago
  > Sometimes it’s better to be explicit than abstract. This is a false dichotomy: after all, "open" is explicit and abstract (w.r.t. actual file systems). The original article from Metz was interesting, but the example here is disappointing. The code was apparently used only once: why generalize? And if you want to generalize, why not make use of two functions: a new one which implements "touch", and the existing os.Chmod?
  • Chris2048 11y ago
    You can only generalize if you understand the original functionality. Multiple examples help infer this, but it this case it was initially assumed what was wanted... That's the issue. The original programmer never communicated their intention, so we have to figure out what is required from context.