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

[Mark Michelson]

On 12/14/2010 08:28 AM, 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 can't see the benefit requiring an 'operator char[]' conversion 
function over requiring that the key type be a std::string. Both require 
the same types of conversions to be done, but with std::string, you at 
least have some helpful built-in operators to help build the string for 
you. I wouldn't be surprised to find that most implementations of 
operator char[] for a key type would end up using std::string in order 
to build the char sequence.

The other reason I don't like this idea is that it doesn't allow for 
std::string to be used as a key type any more since std::string does not 
have an 'operator char[]' conversion function (though it really seems 
like it should).

Mark Michelson