
Unhelpful abstractions - spacey
http://dave.cheney.net/2016/02/06/unhelpful-abstractions
======
mmarx
> 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
Probably worth mentioning that mode will be ANDed with the current umask, so
_explicitly_ setting the file mode requires a little more work.

~~~
mmarx
But this is also true if the file does not exist, and the could would then
fail anyways.

------
junke
> 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
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.

