On Fri, 10 May 2013 18:20:34 +0100, Robert Kern wrote: > According to Steven's criteria, neither of these are instances of the > anti-pattern because there are good reasons they are this way. He is > reducing the anti-pattern to just those cases where there is no reason > for doing so.
But isn't that the case for all anti-patterns? We agree that GOTO is an anti-pattern. That doesn't mean that there aren't valid reasons for using GOTO. Sometimes there are good use-cases for GOTO that outweigh the harm. By calling it an anti-pattern, though, we shift the onus onto the person wanting to use GOTO: justify why you need it, or use something else. Would you object less if I called it a "code smell" than an "anti- pattern"? If so, I accept your criticism, and call it a code smell: the less temporal coupling your API has, the better. > That is why I asked for in-the-wild instances. How about this? http://legacy.thecodewhisperer.com/post/366626867/improving-clarity-by-removing-temporal-coupling Another example of temporal coupling is json_decode in PHP: you must follow it by a call to json_last_error, otherwise you have no way of telling whether the json_decode function succeeded or not. http://php.net/manual/en/function.json-last-error.php > I should > have qualified my sentence to include "according to your criteria" > because people seem to be answering my query out of that context. Now you know how I feel :-) I started this thread asking for help tracking down a blog post describing this code smell, or at least the name of such. Thanks again to Wayne Werner, who came through with the name of the anti-pattern, temporal coupling, and a blog post describing it, although not the one I read all those many moons ago. I never intended to give the impression that *any* use of a separate "enable" method call was bad. I certainly didn't intend to be bogged down into a long discussion about the minutia of file descriptors in C, but it was educational :-) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
