Drew M. wrote:
> If it ain't broke....
IMHO, it is broke. :)
> I don't see a compelling need to rearrange the arguments for the connect
> interface, unless there have been a lot of complaints that I am not aware
> of.
The reason is simple: code shouldn't have to pass any more of these
arguments than absolutely necessary. This being a statically compiled
language, there's only so close we can get to that ideal. I think this
is it.
Perhaps my assumptions are wrong. Do you connect to a DB server on
another server more often than one on the local host? If so, then I can
see putting the server_addr parameter back in front of the user name.
> the arrangement you propose doesn't really feel intuitive.
I agree, it takes some getting used to. The question, then, is whether
it's more useful this way. Usefulness trumps intuitiveness.
> here is how the mysql_real_connect function looks in the C api:
That's no argument. The whole point of MySQL++ is to improve on the C
API, not slavishly copy it. If you just wanted a tight C++ wrapper for
the C API, this ain't it.
> I think that the potential for confusion on this is enough to warrant just
> leaving it alone. I foresee lots of torn-out hair from people trying to
> figure out why they can connect to mysql via the C API (or command line
> client) but not mysql++.
In all the years I've been maintaining and using MySQL++, I remember a
lot more times we've had to try and convince a MySQL++ newbies to try
something with the C API to see if it differs than someone coming from
the C API to MySQL++ and being annoyed at its differences.
It's my contention that most MySQL++ users have little experience with
the C API. It's both possible and desirable to learn MySQL++ only and
ignore the underlying C API. Not always practical, but desirable.
