I thought of one more possibility, which is the simplest of all (in terms of
function signature):
4. Take a single key/value string, containing comma-separated key=value
assignments:
proc = createLookTransform (..., "key1=val1,key2=val2");
Here's where I don't know enough about how OCIO is used everywhere -- can we be
reasonably assured that keys and values will not contain ',' or '=' characters,
so that this syntax is unambiguous? Or might keys and values be so arbitrary
that combining them into strings is a bad idea that's just asking for trouble
down the road?
> On Oct 22, 2016, at 7:08 PM, Larry Gritz <[email protected]> wrote:
>
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
