[vlc-devel] Questions about VLC architecture

[Rémi Denis-Courmont]

	Hello,

Le samedi 20 septembre 2008 15:26:30 Justus-bulk at piater.name, vous avez 
écrit :
> - The objects look like they implement a sort-of poor man's
>   inheritance,

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

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

Regards,

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary