GstStructure mutability question

[José Alburquerque-3]

Hi.  I have a question on the mutability enforcement ability of a
GstStructure.  As I understand it, the structure is owned by a parent
with refcounting capabilities.  The docs say that the structure can make
itself mutable (?) by using the gst_structure_set_parent_refcount()
method, which seems to simply augment the parent's refcount.  I'm
wondering:  Suppose that the parent is refcounted more than once by
other means, would this also make the structure immutable?  Is this
desired/intentional behavior for GstStructure?  Is a GstStructure
supposed to be immutable if its parent is refcounted more than once even
if the gst_structure_set_parent_refcount() method is not used?  Thanks.

-Jose

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Andy Wingo]

On Fri 18 Jan 2008 00:24, José Alburquerque <[hidden email]> writes:

> Hi.  I have a question on the mutability enforcement ability of a
> GstStructure.

Check gstreamer/docs/design/part-MT-refcounting.txt, "Mutable
substructures".

Andy
--
http://wingolog.org/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[José Alburquerque-3]

Andy Wingo wrote:

> On Fri 18 Jan 2008 00:24, José Alburquerque <[hidden email]> writes:
>
>  
>> Hi.  I have a question on the mutability enforcement ability of a
>> GstStructure.
>>    
>
> Check gstreamer/docs/design/part-MT-refcounting.txt, "Mutable
> substructures".
>
> Andy
>  

Thanks for replying.  I'm in the process of reading the documentation.  
In the mean time, my real question may not be directly answered there
because my question is a bit more general.  I'm a bit curious as to why
the GstStructure immutability is related to the parent's ref count and
not to some other criteria.  Is the ref count the best way to implement
immutability?  Is the ref count used because, by design, a GstStructure
*cannot* be modified when its parent is referenced more than once or
could it be possible to reference the parent more than once and still
modify the GstStructure?

In trying to provide C++ bindings, I'm encountering a few difficulties
with GstStructure immutability because in C++, inadvertently, an object
such as a GstCaps may be referenced more than once by a simple C++
statement (by our design, of course) such as:

caps->set_simple("field1", value1)->set_simple("field2",
value2)->set_simple("field3", val3);

In our bindings, the set_simple() method of the Gst::Caps class returns
a "Reference Pointer" (RefPtr)  to the Caps.  (A "Reference Pointer" is
a class that "wraps" other classes, automatically referencing them and
unreferencing them when the class goes out of scope.)  We want this
feature to make referencing and unreferencing of  objects automatic, but
the multiple references caused in this situation (and others similar to
this one that I can describe) makes the GstStructure of the caps
immutable before all the "setting" can be completed.  Can someone see
our predicament?  Thanks.

-Jose

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[David Schleef]

On Sun, Feb 10, 2008 at 09:41:20AM -0500, José Alburquerque wrote:
> In trying to provide C++ bindings, I'm encountering a few difficulties
> with GstStructure immutability because in C++, inadvertently, an object
> such as a GstCaps may be referenced more than once by a simple C++
> statement (by our design, of course) such as:
>
> caps->set_simple("field1", value1)->set_simple("field2",
> value2)->set_simple("field3", val3);

Could you come up with a better example?  You've changed the return
value of set_simple, which seems like a dangerous path to follow for
a language wrapper.



dave...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[José Alburquerque-3]

David Schleef wrote:

> On Sun, Feb 10, 2008 at 09:41:20AM -0500, José Alburquerque wrote:
>  
>> In trying to provide C++ bindings, I'm encountering a few difficulties
>> with GstStructure immutability because in C++, inadvertently, an object
>> such as a GstCaps may be referenced more than once by a simple C++
>> statement (by our design, of course) such as:
>>
>> caps->set_simple("field1", value1)->set_simple("field2",
>> value2)->set_simple("field3", val3);
>>    
>
> Could you come up with a better example?  You've changed the return
> value of set_simple, which seems like a dangerous path to follow for
> a language wrapper.
>
>
>
> dave...
>
>
>  

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).

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.  There is
a difference, of course, and that would be in the usage syntax.  We're
debating whether to use this format or something else, but right now, we
would really like to use it because due to our effort to be type safe,
we are not implementing methods with variable arguments and this would
make it easier for developers to "set" a series of values in
GstStructure fields of the GstCaps (in C++).

-Jose

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[David Schleef]

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.

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



dave...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[José Alburquerque-3]

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...
>
>
>  


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel