This makes the naming unified across C++ / python, and also gets rid
of "getXML" (which is no longer xml).

js/master
commits:
bd559608bdfbbc930634ef78eebd42cda83647da

LGTM,

Did you see my comment in one of the threads about also supporting the .__str__() method?

I did see that comment, forgot to address it in the last post.

I'd prefer to not expose the exact yaml serialization using __str__().

I'm pretty biased against "non-obvious" operator overloading (both in
C and python), so if people want to get the serialized representation
for output purposes I'd prefer an explicit call.

Granted, it may be super handy to have str(config) print out a fully
informative description of the object. This could be as simple as
<class Ocio.Config FULL YAML EMBEDDED HERE>). I just want to make
sure the str representation is not valid parsable yaml, so people dont
accidentally rely on str() when they should be using .serialize().

-- Jeremy



On Tue, Oct 19, 2010 at 3:31 PM, Malcolm Humphreys
<malcolmh...@...> wrote:

LGTM,

Did you see my comment in one of the threads about also supporting the .__str__() method?

On 20/10/2010, at 9:05 AM, Jeremy Selan wrote:

This makes the naming unified across C++ / python, and also gets rid
of "getXML" (which is no longer xml).

js/master
commits:
bd559608bdfbbc930634ef78eebd42cda83647da

Thinking about this topic further, I think the right thing to do it to
have __str__ call through to the C++ ostream implementation for each
class. (If that happens to use yaml, great! But it's not a problem if
it doesn't either).

-- Jeremy

Yep, I was thinking about doing that but it's not straight forward if we don't want yaml-cpp in the public interfaces for the Transforms()s.

It could also be possible if we have some form of Transform()s parameter types / storage. So something in the core lib can just serialize these params into this ostream. This could pave the way for having Transform plugins which can be serialize themselves with out knowing about yaml-cpp.

.malcolm