[vlc-devel] Re: vlc: svn commit r20620 (pdherbemont)

[Pierre d'Herbemont]

Selon Damien Fouilleul <damien.fouilleul at laposte.net>:

> Subversion daemon wrote:
> > r20620 | pdherbemont | 2007-06-18 21:58:16 +0200 (Mon, 18 Jun 2007) | 2
> lines
> > Changed paths:
> >    M /trunk/mozilla/control/npolibvlc.cpp
> >
> > Mozilla: Attempt to match libvlc input to media_instance changes.
> >
> >  > http://trac.videolan.org/vlc/changeset/20620
> >
> >
> hmm, i don't like 'libvlc_media_instance_destroy_and_detach' name and
> what it does, it's actually not what libvlc_input _free() did, as the
> latter only freeed the memory related to the libvlc_input object, not
> the input object itself.

Well that is exactly the difference between libvlc_media_instance_destroy and
libvlc_media_instance_destroy_and_detach.

libvlc_media_instance_destroy_and_detach did exactly what libvlc_input_free did,
plus destroying it's own media_descriptor. It doesn't release the
input_thread_t...

However I certainly agree with the fact that the name is not good at all, I did
that when I discovered that the mediacontrol API did use that trick... Without
much thinking.

> Could you also use proper OO semantics as well,
> libvlc_media_instance_destroy_and_detach means absolutely nothing to the
> 'casual' programmer; try pairing 'get' calls with a matching 'release',
> as most OO language do. you could also use reference counting,i.e:

We currently use the _new constructor plus the _destroy destructor (that's
libvlc historic keyword) and I gladly take your suggestion about having a:

libvlc_media_instance_release()

that destroy the media_instance object but not it's associated vlc's
input_thread_t.

But I am really not fond of the idea to add the extra OO refcount overhead,
Objective-C and other OO languages already do that fine for us... Let's keep the
code simple and don't add more than needed.

Thanks for your suggestions and comments!

Pierre.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html