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

List:       kmail-devel
Subject:    Re: [PATCH] Extract Interface on KMComposeWin
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2005-06-26 18:36:14
Message-ID: 200506262036.15555 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 26 June 2005 20:15, Marc Mutz wrote:
> On Sunday 26 June 2005 13:20, Ingo Klöcker wrote:
> > On Saturday 25 June 2005 10:36, Till Adam wrote:
> > > On Saturday 25 June 2005 10:34, Marc Mutz wrote:
> > > > On Saturday 25 June 2005 09:48, Till Adam wrote:
> > > > > On Saturday 25 June 2005 02:04, Marc Mutz wrote:
> > > > > > Attached patch extracts an interface class, called
> > > > > > KMail::Composer, from KMComposeWin, completely hiding the
> > > > > > latter from the rest of KMail.
> >
> > I don't understand why you made makeComposer() return a pointer
> > instead of a smart pointer class or a reference so that we can get
> > rid of the dreaded C-style pointers.
>
> C-style pointers? Are there C++ style pointers, too?

Of course. For example smart_pointer, etc.

> Funny sentiment 
> for a project where every use of STL gets a raised eyebrow :)

That's just because many of us prefer the easier syntax of the Qt 
containers. We definitely do not prefer pointer arrays over STL.

> But to answer your question:
>
> Oh, that's simple: I'm doing a refactoring, not a redesign. Plus,
> what kind of shared pointer should I return? Either I make something
> like undeletable_ptr (see recent CUJ article), but that doesn't let
> you make a QObject::connect() call, since that takes a pointer, or I
> return a custom smart ptr impl that has a connect member function, so
> as to mimic the non-static QObject::connect. But then, how do you
> model connecting to a composer signal as opposed to connecting to a
> composer slot? Not unsolvable, but certainly not worth it. Leaves a
> reference. References are not copyable. I've seen too many
> programmers fall into this trap. References are evil in that respect.
> I've recently re-programmed Till on that issue, you're welcome to
> request the same treatment :) Leave of course 
> std::tr1::reference_wrapper, but - uh, oh - that reeks of STL.
>
> > The only reason I can think of is that it
> > requires less changes (because you can keep all those win->foo()
> > calls).
>
> If you get TT to make QWidget's not "C-style pointer"-based, then
> I'll change the return type to match. This interface is-a QWidget, so
> why should I change this from the accepted standard for QWidgets?

Okay. Thanks for the detailed answer.

> If there's no code objections, I'd like to commit this now. Patch's
> been up two days now and if all that comes back is a discussion as to
> the name, I for my part consider the patch perfect :)

Go ahead.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


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