Rick Gutleber wrote:
> It certainly seems like it wouldn't hurt to have the manip.cpp stuff
> check for two different classes instead of just one.
I have no problem with that. Yet another case where slowing MySQL++
down a bit doesn't matter. It's ugly, but there were plenty of such
things in v2, which got cleaned up in v3.
> I'd recommend
> doing the SQLEscaper thing anyway, and only use it in SQLStream for the
> time being.
I don't see any value in that. One can dynamic_cast to SQLStream just
as well as to SQLEscaper. The new interface doesn't buy us anything
until v4, when we'll have freedom to change everything around anyway.
You're welcome to submit a patch to the v4 section of the Wishlist,
however, saying that we should extract the common string escaping
interfaces into a common base class for Query and SQLStream.
>> De-encapsulating this strikes you as good design?
> Of course not. This was just as a temporary measure to see if there was
> some unobvious reason the methods couldn't be static, and since there
> weren't, this means they could go in Connection. It was an experiment,
> not a change.
I wasn't trying to impugn your design sense. I wanted you to look one
step beyond the face value of the comment.
Clearly de-encapsulating a powerful object like Connection just to get
access to a single method is bad design. But, you need the interface in
Query to make the manipulators happy. This interface just bounces the
call through Connection to DBDriver in a nicely encapsulated way.
Moving the interface just rearranges the required indirections, it
doesn't actually effect a real change. If you don't believe it, draw a