You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2008/10/23 15:35:50 UTC

Re: IMPORTANT: FW: [jira] Created: (QPID-1377) C++ Refactor asynch level to enable easier Windows porting

On Mon, 2008-10-20 at 19:30 -0400, Steve Huston wrote:
> Hi Andrew, Alan,
> 
> I would really like some review on this issue as soon as you can
> manage it. I have just a few more things to migrate over to svn in
> order to get Windows port into M4.

Just got back into the office after a couple of days out:

The only real comment I have is that you change is inconsistent between
AsynchIO and AsynchAcceptor.

AsynchAcceptor you've changed to use an AysnchAcceptorPrivate and
delegation (which is the same as the pattern we use in some other places
in th IO code). In AsynchIO you use an abstract base class instead.
Given that each approach is fundamentally the same (at least as far as
machine operations) I'd have preferred them to use the same approach.

Did you have a reason for doing these closely connected classes
differently?

Andrew



RE: IMPORTANT: FW: [jira] Created: (QPID-1377) C++ Refactor asynchlevel to enable easier Windows porting

Posted by Steve Huston <sh...@riverace.com>.
Hi Andrew,

> On Mon, 2008-10-20 at 19:30 -0400, Steve Huston wrote:
> > Hi Andrew, Alan,
> > 
> > I would really like some review on this issue as soon as you can
> > manage it. I have just a few more things to migrate over to svn in
> > order to get Windows port into M4.
> 
> Just got back into the office after a couple of days out:

Welcome back!

> The only real comment I have is that you change is 
> inconsistent between AsynchIO and AsynchAcceptor.

Ok.

> AsynchAcceptor you've changed to use an AysnchAcceptorPrivate and
> delegation (which is the same as the pattern we use in some 
> other places
> in th IO code). In AsynchIO you use an abstract base class instead.
> Given that each approach is fundamentally the same (at least as far
as
> machine operations) I'd have preferred them to use the same
approach.

Good point.

> Did you have a reason for doing these closely connected classes
> differently?

There was very little to do with the acceptor and it was easier and
quicker to do it as I did. I'll change it so all are consistent once I
finish the rest of the merging into trunk.

Thanks for the feedback!
-Steve