bracket-push: Improve exercise description about problem-specifications HOT 5 CLOSED

The best READMEs seem to leave a fair amount of ambiguity, allowing different languages to implement different things without being inconsistent with the spec.

Maybe we could change the README to say "brackets and braces", leaving the interpretation more open.

from problem-specifications.

It was not clear to me that a certain amount of ambiguity is desired. My expectation was that e.g. brackets('{[ ]}') should not raise an exception in one and pass in another track.

The approaches and coding styles are sometimes very different between various languages so maybe it makes sense not to lay everything down to the last detail. Didn't really think about that aspect.

from problem-specifications.

If I understand, one issue is if it's fair for test programs to test three kinds of braces when the readme mentions only two. I suppose someone could write some logic that only worked for two kinds of braces but not be easily adapted to three, then be frustrated to discover they must handle three. I expect that's rare though, and Katrina's suggestion of making the readme a little less specific might help in those cases.

Another issue is differences between the implementation in the Go and Javascript tracks. I think they currently have the same test cases and expect the same results, other than the Go API also having this error return. None of the current test cases are considered errors though, so the interpretation (that non-brace content would be an error) of the Go example program doesn't seem relevant. Solvers in the Go are not compelled to make the same interpretation and in fact are free to return nil (no error) in all cases.

from problem-specifications.

I was thinking the wrong way. If it would be a normal application I would make sure that the behaviour with other characters than brackets is tested. But here we actually win some freedom by not testing it because every user can decide independently how to handle it.

Nonetheless I like Katrina's suggestion to say "brackets and braces" even though its only a very small change.

from problem-specifications.

Thanks for helping clarify.

from problem-specifications.