object.enable() anti-pattern

Robert Kern robert.kern at gmail.com
Fri May 10 11:33:09 EDT 2013


On 2013-05-10 15:01, Roy Smith wrote:
> In article <mailman.1527.1368188358.3114.python-list at python.org>,
>   Robert Kern <robert.kern at 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




More information about the Python-list mailing list