Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!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 16:33:09 +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> <mailman.1527.1368188358.3114.python-list@python.org> <roy-F6FC44.10011410052013@news.panix.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: <roy-F6FC44.10011410052013@news.panix.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1537.1368200002.3114.python-list@python.org>
Lines: 64
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45110

On 2013-05-10 15:01, Roy Smith wrote:
> In article <mailman.1527.1368188358.3114.python-list@python.org>,
>   Robert Kern <robert.kern@gmail.com> wrote:
>
>> 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.
>
> As I mentioned earlier in this thread, this was a common pattern in the
> early days of C++, when exceptions were a new concept and handled poorly
> by many compilers (and, for that matter, programmers).
>
> There was a school of thought that constructors should never be able to
> fail (because the only way for a constructor to fail is to throw an
> exception).  The pattern was to always have the constructor succeed, and
> then either have a way to check to see if the newly-constructed object
> was valid, or have a separate post-construction initialization step
> which could fail.
>
> See, for example, the isValid() and Exists() calls for RogueWave's
> RWFile class (http://tinyurl.com/c8kv26g).  And also,
> http://tinyurl.com/cgs6clx.
>
> Even today, there are C++ implementations which do not use exceptions.
> Some are for use in embedded or real-time systems where things need to
> be strictly time-bound and/or memory-bound.  Others are for historical
> reasons (http://tinyurl.com/6hn4zo).
>
> Once people were used to writing "can't fail" constructors in C++, they
> often continued using that pattern in other languages, where the
> underlying reasons no longer made sense.  Quite possibly, they never
> even knew the underlying reasons; they were taught, "Constructors must
> never fail", and assumed it was a universal rule.

Right, this is one of the "bad reasons" I talk about later in my message. The 
authors had a reason in their mind for doing it (they thought it was a universal 
rule); it was just a bad one. It's more useful to talk about why people thought 
they should follow that pattern than to just say "there is no reason to do this".

> This, BTW, is one of my biggest beefs with the classic Gang Of Four
> pattern book.  It presents a bunch of patterns as being universally
> applicable, when in reality many (if not most) of them are highly C++
> specific.
>
> BTW, whenever I read things like, "I think everyone agrees", I
> automatically assume what the writer really meant was, "I, and all the
> people who agree with me, think".

Hah! Fair enough. I actually meant it to emphasize that I thought that Steven 
was overly reducing his statements to something that was trivially true, 
sacrificing content for validity. I will suggest that your interpretation of 
that phrase is more appropriate when the speaker is proposing something of their 
own rather than (partially) conceding a point. The exaggeration is only 
self-aggrandizing in the former case.

-- 
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