OK, I have three choices for you to consider:
1. Add a new version that passes an array_view of pair<string,string> for
token/value, like this:
typedef std::pair<std::string, std::string> KeyValuePair;
ColorProcessor* createLookTransform (string_view looks,
string_view inputColorSpace,
string_view outputColorSpace, bool inverse,
array_view<const KeyValuePair> context) const;
(remember that an array_view can be a true array, or a std::vector, or a
single element passed directly)
2. Add a version that passes separate array views for keys and values:
ColorProcessor* createLookTransform (string_view looks,
string_view inputColorSpace,
string_view outputColorSpace, bool inverse,
array_view<string> context_key,
array_view<string> context_value) const;
3. Keep the current signature:
ColorProcessor* createLookTransform (string_view looks,
string_view inputColorSpace,
string_view outputColorSpace,
bool inverse=false,
string_view context_key="",
string_view context_value="") const;
but allow the key and value to be comma-separated lists and pair up on the
inside, if you catch my drift, like:
proc = createLookTransform (..., "key1,key2", "value1,value2");
Thoughts? Choice #1 is probably the most foolproof, in the sense that there's
really no way to have a mismatch between the number of keys and values, but
it's also the more complex to call (you need to assemble an array of
KeyValuePair's). Choice #3 has the appeal of not adding any new function entry
points (most backward-compatible), but I'm not sure if the scheme is confusing
or not.
> On Oct 22, 2016, at 6:17 PM, Larry Gritz <[email protected]> wrote:
>
> Sure. If three is a possibility, then I'll just add a version that's
> arbitrary, and I'll do it for all the current color functions that take
> key/value pairs.
>
> Which OIIO major release are you using?
>
>
>
>> On Oct 22, 2016, at 5:28 PM, Jep Hill <[email protected]> wrote:
>>
>> Thanks Larry.
>>
>> I’m in the camp for keeping it flexible, if possible. Along the lines of
>> your point, I hadn’t needed more than one key/value pair for years; and now
>> I’m finding I need two, possibly three. Would passing a map/dictionary be
>> the way to go?
>>
>> Also, would it be possible to roll-in whatever solution is decided upon to
>> the colorconvert function? This would be very helpful in cases where
>> colorspace definitions contain context based looks.
>>
>> Cheers,
>> Jep
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> [email protected]
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
