object.enable() anti-pattern

[Robert Kern]

On 2013-05-11 08:51, Steven D'Aprano wrote:
> 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.

Yes, that was the point I was making. You seemed to be defining away the 
legitimate instances as not instances of the pattern at all because they were 
legitimate, and that appeared to me to be defeating the purpose of having the 
discussion.

On a related note, I *don't* think it's a good idea to phrase it as "justify why 
you need it". I don't think that gives very good guidance to a novice when they 
are given the task of designing something. People can come up with a 
justification for just about anything, especially when they are only justifying 
things to themselves. I think it's more important to just talk about the 
situations where a pattern is useful, and the common situations where people, 
for whatever reason, *think* that a pattern is useful, but isn't. Naming it a 
Pattern or Anti-pattern is really just a measure of how bad the latter half of 
that is compared to the first half, and is less interesting than the discussion 
itself. That's why I had a bug up my ass about what looked like the exclusion of 
the "good" uses. It's the good examples that give novices an idea of what a good 
justification looks like, so they can tell if the justification they are giving 
themselves measures up.

> 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 was not really my objection. I was objecting to the way you appeared to be 
defining the particular pattern in question. But as we appear to agree on the 
important matters, I won't press it further.

>> 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

There's something about Java mixedCase that makes my eyes glaze, so I'll take 
your word for it. :-)

> 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 suspect that the author might say something about error checking being 
optional. But yeah, terrible API. :-)

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco