On 10 May 2013 15:01, Roy Smith <[email protected]> wrote: > In article <[email protected]>, > Robert Kern <[email protected]> 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
