even more KProcess (Re: Ouch?)

[Marc Mutz]

On Saturday 21 February 2004 01:02, Waldo Bastian wrote:
> On Sat February 21 2004 00:40, Marc Mutz wrote:
> > On Friday 20 February 2004 11:15, Marc Mutz wrote:
> > > I understand that combining the funtionality of these subclasses
> > > so they can be used together is the driving force here, but
> > > creating a monster API a la KListView should be avoided. Perhaps
> > > by using an aspect-oriented approach. Carsten? Or by classic
> > > Decorators.
>
> Can you give an example of how that would look like? E.g. we have
> now:
>
> 	void setUseShell(bool useShell, const char *shell = 0);
>
> for shell support. And:
>
> 	void setUsePty(Communication comm, bool addUtmp);
> 	KPty *pty() const;
>
> for pty support. How would that look like with these other
> approaches?
<snip>

I have not recently looked at AOP, but it would look something like (of 
course, you'd use typedefs to make the class name more pleasing)
  KProcess<KProcess::Shell,KProcess::PTY> shellPtyProc;
  KProcess<KProcess:Buffered,KProcess::Shell> ioShellProc;
or
  KProcess< PTY, KProcess<Shell> > shellPtyProcess;

implemented along the lines of:

template< class Aspect, class P = KProcessBase >
class KProcess : public P, private Aspect<P> {
public:
	/// ctor, dtor
	/// new interface elements

protected:
	// reimplementations of virtual KProcessBase methods:
	void myFoo( blah, blub ) {
		if ( !Aspect::preMyFoo( blah, blub ) )
			Aspect::postMyFoo( P::myFoo( blah, blub ) );
	}
}

Yes, laugh. This is AOP (well, almost, I guess), *sigh*. In C, OOP looks 
funny, too. To save memory, we can Implement KShellProcess, 
KBufferedIOProcess, KPtyProcess as _subclasses_ of KProcess<Shell>, 
KProcess<BufferedStdIn,KProcess<BufferedStdOut,KProcess<BufferedStdErr>>>, 
and KProcess<PTY>, resp. and thus hide the template-based 
implementation. You could still add other aspects to these: 
KProcess<PTY,KShellProcess>, etc.

Which reminds me that QObjects cannot be template classes - *sigh*.

The decorator approach is similar, but uses run-time composing instead 
of compile-time, so it can't change the interface (although you can of 
course save pointers to the "intermediate products").

KProcess * shellPtyProcess =
   new KProcess::Shell(param1, param2,
   new KProcess::Pty( param1, param2, new KProcess(parent,name)));
or
KProcess shellPtyProcess proc;
proc.addExtension( new KProcess::Shell( param1, param2 ) );
proc.addExtension( new KProcess::PTY( param1, param2 ) );
proc.addExtendion( new KProcess::Pipes(2 /*outgoing*/, 1 /*incoming*/));

The decorator/extension stuff can be hidden by using
  KProcess * proc = KProcess::create( Shell|PTY );
but then you lose the ability to add parameters.

Marc

-- 
Kight, Khis Kay KDE Krogramms Kre Kasier Ko Kdentify; Gnome Grograms
Gn Ghe Gther Gand Gtart Gith G.
            -- "diskord_" in heise.de newsticker comment (translated)