[gst-devel] GstStructure mutability question

[José Alburquerque]

David Schleef wrote:
> On Mon, Feb 11, 2008 at 04:07:14PM -0500, José Alburquerque wrote:
>   
>> A better example would be what happens with our RefPtr wrapper class (which 
>> wraps objects and automatically increments/decrements their references) and 
>> when it is "cast" (see this bug report I filed hoping for some possible 
>> solution: http://bugzilla.gnome.org/show_bug.cgi?id=510301).
>>     
>
> One possible workaround for this is to add a wrapper_refcount field
> that is only used for language wrappers.  Language wrappers would
> increment the wrapper_refcount field to indicate that the refcount
> is due to the bindings only, and not to be used as in determining
> writablity.  (This is only a suggestion.  Don't know if it would
> work, or even wise.  Definitely something we need to address in 0.11.
> Actually, we needed to address it in 0.7, but it got dropped because
> of more pressing issues.)
>
>   
>> The reason we want  to design our Caps::set_simple() method to return a 
>> "pointer" (in fact it is our RefPtr wrapper class) to the caps is to allow 
>> the "chain of sets" you see above.  Your gst_caps_set_simple() returns 
>> void, so I don't really see where the danger would be.
>>     
>
> The obvious danger is that you waste application developers' time.
> Based on my observation of new developers in the past, the thought
> process would go something like this:
>
>   - Hmm, Caps::set_simple() returns Caps, but the C version doesn't.
>   - I wonder if the C documentation is correct for the C++ function.
>   - I wonder if the C++ function is supposed to work like
>     gst_caps_make_writable(), and I'm supposed to assign it to my
>     local variable.
>   - (looks in the C++ documentation, finds nothing, becuase "it's obvious")
>   - (asks on IRC, gets no conclusive answer)
>   - *frustration*
>
> Gratuitous differences are completely wasteful, since they require
> extra documentation, extra neurons to remember the differences, and
> extra bugs because people don't remember (or never knew) the differences.
>
> However, if a C function completely goes against language style, feel
> free to change it.  The python bindings do this quite frequently,
> because otherwise the combination of gstreamer+python would feel like
> writing C with python syntax.  This is not such a case.
>
>   
Point well taken.  Please keep in mind that it hasn't been decided if we 
will be using this method and be assured that it is not for gratuitous 
purposes.  I understand that this case seems as if there should be no 
difference between the C and C++ style, but if we will not be using the 
variable argument style methods, I thought that such an addition would 
be sort of useful.

When I began working in the (already begun) wrapping process, I noticed 
that something similar was used for linking  elements (e.g. 
element->link(element2)->link(element3)) and I thought that this same 
method could be used in this Caps case, but it hasn't been in this case.

I really want to apologize for bringing up this request, I'm sure it's 
coming from a newcomer at this point so please forgive me because I 
probably haven't considered everything and shouldn't be making request 
that I don't even understand.  I wish you well in your continued 
development of this excellent software.  I'm sure a solution will 
present itself in the future at some point.  Please forgive my 
inconveniencing you.  Thanks for your response.

-Jose

> Also, set_simple is variadic for a reason.  Setting a single caps field
> may take multiple values, for example, when setting fractions.
>
>
>
> dave...
>
>
>