object.enable() anti-pattern

[Steven D'Aprano]

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