The impoliteness of overriding methods

[H. S. Teoh]

On Thu, Dec 20, 2012 at 08:19:58PM +0100, foobar wrote:
> On Thursday, 20 December 2012 at 10:15:47 UTC, Benjamin Thaut wrote:
> >Am 20.12.2012 10:44, schrieb sclytrack:
> >>
> >>@mustcallbefore @mustcallafter
> >>
> >>Would these be automatically called in all derived versions?
> >>
> >>@autocallbefore  @autocallafter
> >>
> >
> >
> >I think @mustcall would suffice, because it won't compile. If it
> >does not compile the customer will investigate what broke and fix
> >it (hopefully) appropriately. But of course the other options
> >would be nice too.
> 
> So basically you suggest adding a language feature to cover up
> library developer's poorly designed API? IMO, if you want to provide
> a frozen API under the current inheritance design, you should use
> pimpl design pattern in the first place and not ask for features to
> solve the problem after the fact.

Yeah, it doesn't make sense for the base class implementor to say "you
must call function X after you're done function Y". The base class API
should be *designed* so that function X *will* be called after function
Y, no matter what the derived class code does.

OO code that breaks if methods are called in the wrong order (or certain
methods fail to get called) is broken by definition. The object's
internal state must remain consistent no matter what sequence its
methods are called. This is a fundamental tenet of OO design.


T

-- 
Amateurs built the Ark; professionals built the Titanic.