On 10 May 2013 15:01, Roy Smith <r...@panix.com> wrote: > In article <mailman.1527.1368188358.3114.python-l...@python.org>, > Robert Kern <robert.k...@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.
It's not just because of exceptions. In C++ virtual method calls in a constructor for a class A will always call the methods of class A even if the object being constructed is actually of a subclass B because the B part of the object isn't initialised when the A constructor is called. There may be a better way to do this since I last used C++ but as I remember it the two-phase pattern was a recommended way to implement polymorphic behaviour during initialisation. Oscar -- http://mail.python.org/mailman/listinfo/python-list
