Hacker News Reader

Comment by snarfy | Hacker News Reader

If bar() returned the mutated state, he could just do:

    foo(baz(bar()))

View on HN

I think a better design would be to separate mutators from pure functions. If a procedure mutates state, it should have a void return type, and if a procedure returns a value it should be a pure function that doesn't mutate state.

This is, of course, a rule of thumb, not a hard law. Some exceptions:

1. I think it's okay (and in fact, idiomatic in C) to mutate state and return some sort of information about what occurred (i.e. a success flag, a number of characters written, etc.).

2. Isolated mutations such as logging sometimes make sense in an otherwise pure function.

I'm a fan of fluent design myself, and dislike flags.

    return foo().baz().bar();

With flags you start with success/fail, and end up with HRESULT.

I'd agree with you in some languages, but in C this would be prohibitively difficult. In general, good fluent design uses immutable objects, which makes it basically just a syntactic sugar for functional programming. While fluent syntax is nice, the functional semantics are the real value, and are much easier to do in C (although, as soon as you add in memory management, functional programming often becomes prohibitively difficult too).

Reply on news.ycombinator.com