[asterisk-scf-dev] Changes regarding state replicator keys

[Brent Eagles]

On Tue, Dec 14, 2010 at 08:29:17AM -0600, Kevin P. Fleming wrote:
> On 12/14/2010 05:53 AM, Brent Eagles wrote:
> > On Mon, Dec 13, 2010 at 01:39:06PM -0600, David M. Lee wrote:
> >> On Dec 13, 2010, at 12:01 PM, Mark Michelson wrote:
> >>
> >>> 1) Instead of using a templated type for the key, use std::string.
> >>> std::string has a .c_str() method that will give a const char * to the
> >>> actual string content, and std::string has a size() method for reporting
> >>> the size of the string.
> >>
> >> +1.  If you have some class you want to use for your identifier, you
> >> just need to make sure that you can convert that class to std::string.
> >>
> >> Conversions from std::string to the id class are probably an
> >> anti-pattern, since you're then using the identity column for more
> >> than just identity.  You can easily put such information in the value
> >> that's being stored, so that's not too limiting.
> >
> >
> > I had to think about this one a little bit because I didn't quite get
> > David's point. It did finally dawn on me that we were talking
> > specifically about replication, not general database type stuff.  *If*
> > we were building some mechanism for storing arbitrary data, then it
> > would make sense to have some versatility with respect to the key type.
> > However, this is specific to replication so it is not that big of a deal
> > to restrict the key type to strings.
> >
> > On a related note, does memcached restrict key length?
> >
> > <snip>
> >
> > I also agree with David on the other two possibilities, so I'm just
> > going to snip those out.
> 
> My preference would be to not restrict the user of the template to only 
> being able to use std::string for keys. I can easily envision 
> applications where the key will be a structure of multiple fields, and 
> forcing the user of the template to have to convert to/from std::string 
> seems unnecessary.
> 
> My vote would be for the template to just continue to accept a template 
> type parameter (K), and require that that type have a size() member 
> function, an 'operator char[]' conversion function, and a constructor 
> that accepts 'char[], int'.

I forgot to mention, I think the concern about assuming that the
identity type implement certain methods is unfounded. Its actually kind
of the whole point and can be very powerful. It's like "duck" typing, if
the template parameter can be used in the way defined in the template,
you are good to go.

What really starts to bend your noggin' is when you figure out that
template methods are only instantiated if they are used. For example, if
a template contains a method X that calls xyz() and you instantiate one
with a class that does not implement  xyz(), you won't have a problem if
you never use X on that template instance!!

Anyways, given all of that it seems whether you keep things as templates
or strings is more of a preference then a technical issue.

Cheers,

Brent