From: Warren Young Date: July 13 2007 5:45am Subject: Re: Connection::connect() interface is changing List-Archive: http://lists.mysql.com/plusplus/6776 Message-Id: <46971163.8010800@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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.