[gst-devel] GstStructure mutability question
jaalburquerque at cox.net
Mon Feb 11 23:54:12 CET 2008
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.
> Also, set_simple is variadic for a reason. Setting a single caps field
> may take multiple values, for example, when setting fractions.
More information about the gstreamer-devel