[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KParts API: thinking about the future (patch)
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2002-03-03 23:35:10
[Download RAW message or body]

On Monday 04 March 2002 01:17, aleXXX wrote:
> Isn't it quite pointless to make a private function virtual ?

Somehow I expected this question since that was exactly my thought when Dawit 
mentioned this last week and I really needed the web page he referred to 
before I understood.

See http://www.cuj.com/experts/1812/hyslop.htm?topic=experts and sorry for 
forgetting this link in my initial mail!

> Whether the implementation is in the header or in the cpp doesn't really
> matter, except for inlining. We can do it also with David's approach.
> Simply implement your own version of the public virtual functions. You
> could even do:
>
> class MyPartThingy:public KParts::ReadOnlyPart {
> ...
> public:
>    virtual bool openStream() {return doOpenStream();}
>    virtual bool writeStream(const QDataStream &s) {return doWriteStream(s);
> } virtual bool closeStream() { return doCloseStream(); }
> private:
>    virtual bool doOpenStream() { return false; }
>    virtual bool doWriteStream( const QDataStream& ) { return false; }
>    virtual bool doCloseStream() { return false; }
> ...
> };

After reading the above link you'd probably agree that public methods usually 
shouldn't be virtual. For me it was a definitive eye-opener.

> Where's the difference between
>
> public:
>    virtual bool doSomething();
>
> and
> public:
>    bool doSomething();    //calls doSomethingImpl();
> protected:
>    virtual bool doSomethingImpl();
>
>
> I don't see any.

Extensibility. With a single virtual public method you can't ever execute 
code around the virtual method call. By making the virtual implementation 
virtual and private the real method that is called inside the base class can 
still do other processing around the call.

Martijn
[prev in list] [next in list] [prev in thread] [next in thread]