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
--
http://mail.python.org/mailman/listinfo/python-list
