Re: [xine-devel] internal API function renaming

[Michael R. <mr...@us...>]

Hi Thibaut,

> my opinion, i don't like to use function pointers when it's not
> needed, so i prefer the global helper functions approach.
> Michael, you can see our helper functions as static methods of a xine
> engine utility class. ;)

Well, ok, seems I am outvoted.

What I really want to avoid (<- "want to" means we are not too bad 
yet ;) ) is mixing of paradigms:
* use global functions, only fall back to function pointers, when 
  necessary
  (if we would adopt this style, we would have to change audio and
  video decoder loops, buffers, config, metronom, osd, scratch
  because they all use the object oriented approach with function
  pointers although not necessary)
* be object oriented and use function pointers, only fall back to
  global functions, when they do not belong to any object or are just
  helper/util functions

So for the migration, I can live with the #ifdef solution, but as the 
internal interface become more stable, I would really like to change it 
into two structs and move some functions to pointers.

Of course, I would also like to propose extra_info->reset() and 
extra_info->merge() as well as stream->info->get()/set(). But I guess 
my chances to convince you are quite limited...   ;)

And to make things even more complicated, I would like to group all 
functions and structs one type of plugin is allowed to access into an 
interface structure. (something like demux_iface_t would contain 
pointers to the demuxer helper functions and to available structs like 
xine_stream_t) Convention could then be made that all plugins receive 
xine_t on class init and <type>_iface_t on instance init. This way, who 
sees what would be really clear and would be enforced by the compiler 
(because calling a helper that is not meant for you is impossible).

Michael

-- 
panic("Attempted to kill the idle task!");
	2.2.16 /usr/src/linux/kernel/exit.c