From: Warren Young
Date: April 5 2005 6:23pm
Subject: Re: RFC: Row::operator[] change
List-Archive: http://lists.mysql.com/plusplus/4225
Message-Id: <4252D78F.2050204@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Earl Miles wrote:

> Warren Young wrote:
> 
>> But recently, it came to me that the integer overloads were probably 
>> the least useful of the bunch in real-world code.  Intelligent 
>> database design doesn't make the client code dependent on the number 
>> or order of database columns.  So, I wonder if it would have been 
>> better to keep operator[](const char*) instead.
> 
> 
> This depends a lot on how important lookup speed is. The integer lookup
> is bound to be faster than the string lookup. Though there's already
> enough of a speed hit in the mysqlpp::Row stuff that it may not matter.
> 
> However, I can say that my code currently does use the numeric index 
> lookup, because it knows what order the fields are in (they match
> another list it's keeping). So there's at least one instance of real
> world code that uses it.

Noted, but study the patch a little more carefully: it still provides 
Row::col_num() to get a field by column number.

The question ultimately is, which of the two methods of access should be 
given the more convenient array index access method?

Code like in lib/custom.h isn't meant to be read very often.  Code like 
in the MySQL++ examples is definitely intended to be read, often: it 
must be as clear as possible.  Considering just these two examples, it 
would seem logical that it's okay for custom.h to use col_num() lookups 
because clarity isn't as valuable as speed here, while the examples 
should do lookups by column name, in the interest of maximum code clarity.