Re: [Mlt-devel] RFC: MLT Properties 1.0

[Dan D. <da...@de...>]

On Sun, Oct 2, 2011 at 12:57 PM, Brian Matherly <pez...@ya...> wrote:
> Dan,
>
>
>>A lot of things came up in recent discussion with Brian. I decided to
>>make a quick summary of changes I have been thinking about. I am
>>thinking these changes will go into the forthcoming version 0.8, but
>>there will of course be an interim version before then.
>>
>>http://www.mltframework.org/twiki/bin/view/MLT/RfcMltProperties1
>
>
> I've been thinking about your RFC. It looks like good stuff.
>
> I want to make sure I understand exactly what you are thinking. Let me know if this is right:
>
> 1) Delete mlt_geometry.h/c. No file will replace it. Any "geometry logic" will be moved to the property/ies files.
> 2) Add new structures to mlt_types.h: mlt_time, mlt_color, mlt_rectangle
> 3) Add new functions to mlt_property/ies to return the new structure types by value
>
>
> Do I have it right?

yes

> Why do you think it best to return by value rather than by reference? I suppose by-value is simpler for the bindings, but it may be limiting if a new type is needed someday. For example (sorry for going back to this), if there ever were a mlt_font. The structure would have:
>
> struct mlt_font
>
> {
>    int size;
>    char *family;
> };
>
> In this case, it would be disadvantageous to return by value because it would not be clear who owns the memory pointed to by "family". If returned by reference, then the caller would own the memory and would be responsible for cleanup. Maybe I'm over thinking it.
>

Passing simple structs by value is just easier and less error prone
esp. in C, but your example is not a simple struct and does not fall
under that handling. This is not an all-or-nothing situation. mlt_font
is not a part of this, and I am not willing to talk about it at this
time.

> Also, I'm curious: What is your aversion to creating more mlt types (like mlt_geometry)? I haven't been around long enough to understand the disadvantage of the custom types in their own files. The current mlt_geometry method seems handy to me.
>

Yes, it is handy, but it is tool designed for something that is
somewhat abused with scalar (single component) values (frei0r) and
does not handle strings. It will be even more handy when unified with
properties as the primary goal is generic property animation. I have
an aversion to creating sophisticated types for color and rect when I
have no plans to provide operations for them. If we do up creating
some utility functions, they can just be passed by value or reference
as seen fit.

-- 
+-DRD-+