From: Michael R. <mr...@us...> - 2003-11-13 21:57:20
|
Hi again, > > That could mean quite some work, since a good deal of these members > > are used from outside. If we really want to do this before 1.0, I > > think we should do it before rc3 (at least that's what the TODO > > says). Next issue would be: xine_stream_t is not the only struct > > exposing its members... > > I thought of something when i was coming to work today much less > intrusive than creating two structs. I'm attaching the patch so you > can get the idea. it would enforce the public/private separation > without requiring new structs and thousands of typecastings. > > Several variables that are on the public part shouldn't be there > (comments added). moving them will cause some plugin compilation to > fail and therefore it would be easier to fix those. Nice idea, ... but ( <- I guess you expected that :) ) I would prefer the way with the two structs. One reason is that during my last engine modification (vo_frame->stream now allowed to be NULL), an idea crossed my mind that a very complex post plugin (whatever it might be doing) could actually implement its own xine_stream_t interface and have vo_frame->stream of the frames it emits point to this. Output layer could then access parts of this (metronom for example). This is just an idea, nothing substantial, but it would be more clear with separated public/private structs of xine_stream_t. The other reason is my feeling again. We are using the object oriented C approach everywhere else in xine. Moving away from this paradigm for one of the most basic structs feels ungood to me. But I agree with the separation you suggest. (Although as said eariler, I would make the additional helper functions member pointers...) Michael -- panic ("No CPUs found. System halted.\n"); 2.4.3 linux/arch/parisc/kernel/setup.c |