Hacker News new | ask | show | jobs
by hinkley 235 days ago
The example in the wiki page is far more rudimentary than the ones I encountered when I was shown this concept. Trivial, in fact.

CQS will rely on composition to do any If A Then B work, rather than entangling the two. Nothing forces composition except information hiding. So if you get your interface wrong someone can skip over a query that is meant to short circuit the command. The constraint system in Eiffel I don’t think is up to providing that sort of protection on its own (and the examples I was given very much assumed not). Elixir’s might end up better, but not by a transformative degree. And it remains to be seen how legible that code will be seen as by posterity.

1 comments

That's still not really answering my question for you, which was less clear than intended. To restate it:

> The one place this advice falls down is security - having functions that do things without verifying preconditions are exploitable

My understanding of your comment was that "this advice" is CQS. So you're saying that CQS commands do not verify preconditions and that this is a weakness in CQS, in particular.

Where did you get the idea that CQS commands don't verify preconditions? I've never seen anything in any discussion of it, including my (admittedly 20 years ago) study of Eiffel.

And I remain confused by your confusion.

If A then B()

Versus

B()

Somewhere there’s a B without the associated query. Call it what you want, at the bottom of the tree two roads diverge. Otherwise there is no Separation in your CQS.

ETA: once you get down to the mutation point you aren’t just dealing with immutable data. You’re moving things around, often plural.