Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Robert Kern <robert.kern@gmail.com>
Subject: Re: object.enable() anti-pattern
Date: Fri, 10 May 2013 13:19:05 +0100
References: <518a123c$0$11094$c3e8da3@news.astraweb.com> <Z1Eit.289$oB7.283@newsfe02.iad> <518b32ef$0$11120$c3e8da3@news.astraweb.com> <roy-8428A6.09074209052013@news.panix.com> <518be931$0$29997$c3e8da3$5496439d@news.astraweb.com> <mailman.1501.1368124461.3114.python-list@python.org> <518c5bbc$0$29997$c3e8da3$5496439d@news.astraweb.com> <roy-6D8B98.23095509052013@news.panix.com> <518c7f8e$0$29997$c3e8da3$5496439d@news.astraweb.com> <Hm0jt.6$I26.5@newsfe26.iad> <518cd360$0$29997$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
In-Reply-To: <518cd360$0$29997$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1527.1368188358.3114.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45093

On 2013-05-10 12:00, Steven D'Aprano wrote:

> But either way, that's fine. You've found an object where it does make
> sense to have an explicit "make it go" method: first one entity has
> permission to construct the object, but not to open the underlying file.
> Another entity has permission to open the underlying file, but not to
> create the object. I have no idea whether this is a reasonable security
> design or not, it actually sounds a bit rubbish to me but what do I know?
> So let's treat it as a reasonable design.
>
> As I've said, repeatedly, that's not what I'm talking about.
>
> When you DON'T have useful things that can be done with the object before
> calling "enable", then it is an anti-pattern to require a separate call
> to "enable" method, and the enable functionality should be moved into the
> object constructor. If you DO have useful things that can be done, like
> pass the object to another entity, for security, then that's a whole
> 'nuther story.

I'd be curious to see in-the-wild instances of the anti-pattern that you are 
talking about, then. I think everyone agrees that entirely unmotivated "enable" 
methods should be avoided, but I have my doubts that they come up very often. Do 
programmers have a natural tendency to make an extra, completely unnecessary 
method? I would think that they have a natural tendency to the opposite.

In my experience, everyone has a reason in mind when they follow a 
pattern/anti-pattern. It is pretty rare that someone just does some specific, 
nameable thing for no reason at all. There is no need to call out an 
anti-pattern for which no one has a reason to do it. But there is a continuum of 
reasons. Some reasons are better than others. Some reasons only apply in a small 
set of circumstances but seem like they would apply more generally, at least to 
novice programmers. Programmers can be wrong about what they think the 
(anti-)pattern actually achieves. The whole point of naming an anti-pattern is 
to discuss those reasons, show where they are misapplied, where YAGNI, why 
novices overuse it, other patterns that should be used instead, and also the 
circumstances where it is actually a good pattern instead.

To artificially limit the discussion of the anti-pattern to the trivial, 
entirely unmotivated case forbids most of the interesting and instructive parts 
of the conversation.

-- 
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