[vlc-devel] Questions about VLC architecture
rem at videolan.org
Sat Sep 20 15:09:04 CEST 2008
Le samedi 20 septembre 2008 15:26:30 Justus-bulk at piater.name, vous avez
> - The objects look like they implement a sort-of poor man's
An object can only implement one (or zero) "interface", usually in the form of
a plugin capability (set_capability() in the module header). No more than one
single interface per object, and no class/inheritance. Lets not be driven
crazy trying to do provide proper OOP with C like those substance-abusing
> but without the notational convenience, conciseness and
> type safety of an object-oriented language.
We do have some level of type-safety using VLC_OBJECT. But afterall, this is
not so safe C, not hyper-strict C++.
> I guess this is mostly a legacy issue?
In my not-so-humble opinion, yes. Unfortunately, it seems not everyone agrees.
> Secondly, it looks like all kinds of objects are stored inside a
> single tree (per libvlc instance). Why's this? What does this afford
> over and above a conventional design where each subsystem takes care
> of its own data structures?
For historical and misguided reasons. This is a huge mess with regard to
threading now. The patch removing all vlc_object_find.*() usages is welcome
(I won't bother).
> - Similarly, why does VLC need a central repository of named
> Why cannot each subsystem maintain its own variables?
They can. But then the UI wants to deal with the value...
Big public structures would not really be good either, and cannot enforce
thread-safety (we also have a lot of those).
> To me as a newcomer to VLC code, this variable tree looks unwieldy,
> error prone, and inefficient.
It certainly is error prone, so are the object names, and the objects tree.
But fixing these problem is not exactly very thrilling nor easy a task.
> Again, what does it afford over and above a conventional design where each
> subsystem takes care of its own data structures?
It allows lazy or reckless programmers to not care about how the UI or any
external compoment will mess up with the value.
> And why are dynamically-named variables needed at all?
With the only exception of named global mutex, they really aren't needed.
It's just a convenience.
More information about the vlc-devel