Review: renamed config.writeToStream to config.serialize


Jeremy Selan <jeremy...@...>
 

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

js/master
commits:
bd559608bdfbbc930634ef78eebd42cda83647da


Malcolm Humphreys <malcolmh...@...>
 

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


Jeremy Selan <jeremy...@...>
 

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...@mac.com> 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


Jeremy Selan <jeremy...@...>
 

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

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


Malcolm Humphreys <malcolmh...@...>
 

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

On 21/10/2010, at 2:30 PM, Jeremy Selan wrote:

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


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