Change in API for C++ FieldTable

[Andrew Stitcher <as...@redhat.com>]

This is a classic commit and run! [I'm off for the next couple of days].

I've made a change to the FieldTable API to change the inconsistent
getString() and getInt() functions to getAsString()/getAsInt() to better
indicate what they actually do (after a suggestion from Gordon). The
need a different name as they are inconsistent with the other getXXX()
functions.

I'd argue that they should actually throw an exception if the name-value
pair isn't found, but currently the behaviour is as before (return a
default value).

I've fixed everything in the qpid C++ tree itself, but this is an
externally visible change that affect other client code as well.

If necessary it would be trivial to reinstate the old functions as well
and mark them "deprecated", but I decided not to at this stage, if
someone if massively impacted we can do that.

Regards

Andrew

Re: Change in API for C++ FieldTable

[Alan Conway <ac...@redhat.com>]

On Thu, 2008-10-16 at 11:20 -0400, Andrew Stitcher wrote:
> On Tue, 2008-10-14 at 10:11 -0400, Alan Conway wrote:
> > ...
> 
> > I'd like to see a set of template <class T> get() functions to make the
> > FT more accessible to templated code. That could be in addition to the
> > plain functions for template-shy compilers/developers. It could be done
> > in a separate FieldTableTraits class, but built-in members would be more
> > convenient.
> > 
> 
> +1
> 
> I was thinking of adding this as well, but wanted to go one step at a
> time.
> 
> I'm not clear in my own head at this point whether these would be
> additional to or instead of the current
>     bool getXXX(const string& name, XXX& value);
> member.
> 

> For clarity I'd be adding a member with signature:
>     template <typename T>
>     bool get(const string& name, T& value);
> 

I've been using this pattern:
  template <class T> T* get(const string& name);
returning 0 for not present. 

It's used in qpid::Url, AMQHeaderBody and the never-quite-finished
amqp_0_10::Map

I prefer it somewhat - it avoids copying the value and is more
convenient in some uses - e.g. if you just want to test the type: 
 if (ft->get<SomeType>())

I can live with either though.

Re: Change in API for C++ FieldTable

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2008-10-14 at 10:11 -0400, Alan Conway wrote:
> ...

> I'd like to see a set of template <class T> get() functions to make the
> FT more accessible to templated code. That could be in addition to the
> plain functions for template-shy compilers/developers. It could be done
> in a separate FieldTableTraits class, but built-in members would be more
> convenient.
> 

+1

I was thinking of adding this as well, but wanted to go one step at a
time.

I'm not clear in my own head at this point whether these would be
additional to or instead of the current
    bool getXXX(const string& name, XXX& value);
member.

For clarity I'd be adding a member with signature:
    template <typename T>
    bool get(const string& name, T& value);

Actually this would be pretty simple as the FieldValue code already has
templates that look a lot like this.

Andrew

Re: Change in API for C++ FieldTable

[Alan Conway <ac...@redhat.com>]

On Mon, 2008-10-13 at 17:30 -0400, Andrew Stitcher wrote:
> This is a classic commit and run! [I'm off for the next couple of days].
> 
> I've made a change to the FieldTable API to change the inconsistent
> getString() and getInt() functions to getAsString()/getAsInt() to better
> indicate what they actually do (after a suggestion from Gordon). The
> need a different name as they are inconsistent with the other getXXX()
> functions.
> 
> I'd argue that they should actually throw an exception if the name-value
> pair isn't found, but currently the behaviour is as before (return a
> default value).
> 
> I've fixed everything in the qpid C++ tree itself, but this is an
> externally visible change that affect other client code as well.
> 
> If necessary it would be trivial to reinstate the old functions as well
> and mark them "deprecated", but I decided not to at this stage, if
> someone if massively impacted we can do that.
> 
> Regards
> 
> Andrew
> 
> 

I'd like to see a set of template <class T> get() functions to make the
FT more accessible to templated code. That could be in addition to the
plain functions for template-shy compilers/developers. It could be done
in a separate FieldTableTraits class, but built-in members would be more
convenient.