List:MySQL++« Previous MessageNext Message »
From:Chris Frey Date:April 5 2005 8:19pm
Subject:Re: RFC: Row::operator[] change
View as plain text  
On Tue, Apr 05, 2005 at 11:13:21AM -0600, Warren Young wrote:
> I'm thinking I might have made a design mistake in the name of 
> expediency back in v1.7.10 when I fixed the operator[] overloading 
> problem.

I've thought this for a while, since the postgresql library (libpqxx) seems
to make use of operator[](const char[]) const without any problem.

I know that having specific names for things is a benefit in itself
sometimes, so it's not that big a deal to me.


> 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.
> 
> Obviously I can't change it back until v1.8 or v2.0.  Keeping that in 
> mind, my question is, who would it bother if I changed these semantics? 
>  Who uses integer indexes into a Row object in real-world code?

The numeric order is based on the order of the SELECT statement itself,
and as long as the SELECT specifies all the fields it uses, there is
no danger of an order bug popping up due to an underlying table change.

Some of my code does use the numeric indexes, but generally I try to use
lookup_by_name() as much as possible just to avoid boneheaded bugs.


>  public:
> +  typedef unsigned int size_type;
> +
>    Row() {}
>    Row(MYSQL_ROW d, const ResUse *r, unsigned long *jj, bool te = false) 
>      : res(r), throw_exceptions(te), initialized(false)
> @@ -262,12 +263,12 @@
>    Row& self() {return *this;}
>  
>    const ResUse&  parent() const {return *res;}
> -  size_type     size() const;
> -  //: Returns the number of columns.
> -  const ColData   operator [] (size_type i) const;
> -  //: Returns the value of the field with the index of i.
> +  // Returns the number of columns.
> +  size_type     size() const; 
> +  // Returns the value of the column named 'col'.
> +  const ColData   operator [] (const char* col) const; 
>  
> -  const ColData lookup_by_name(const char*) const;
> +  const ColData col_num(size_type i) const;


I'm not so keen on removing operator[](size_type), but you have a good
reason with the 0.  I should probably run some tests to see how libpqxx
gets around it, or whether they know of the problem at all.  Somehow I
wonder how they could get to version 2.3.0 and not have this bother them.

For comparison, here is the code from libpqxx:

util.hxx:
	typedef long result_size_type;

result.hxx:
	inline field operator[](size_type) const throw ();
	field operator[](const char[]) const;
	field operator[](const PGSTD::string &s) const
		{ return operator[](s.c_str()); }
	field at(size_type) const throw (PGSTD::out_of_range);
	field at(const char[]) const;
	field at(const PGSTD::string &s) const { return at(s.c_str()); }

I would also recommend we consider the use of "at" instead of "col_num",
to make things more like the std libraries.

- Chris

Thread
RFC: Row::operator[] changeWarren Young5 Apr
  • Re: RFC: Row::operator[] changeEarl Miles5 Apr
    • Re: RFC: Row::operator[] changeWarren Young5 Apr
  • Re: RFC: Row::operator[] changeChris Frey5 Apr
    • Re: RFC: Row::operator[] changeWarren Young22 Jun
  • Re: RFC: Row::operator[] changeWarren Young22 Jun
    • Re: RFC: Row::operator[] changeWarren Young25 Jun
Re: RFC: Row::operator[] changeBruce Keats11 Apr