It obviously depends and if an interface need be rather complete as a rule, it should reduce code size since only one struct pointer need be passed one time. A messaging model would make expansion easier since other code would probably not need modifying and can ignore the new notification. Only the source and receiver of the new message would need changing. One registration for a related group of events like passing a "struct playback_events" or a playback_event_notification_callback should definitely reduce size and complexity as a rule. As of now we've got a separate callback and registration for each individual event which is messy.
----- Original Message ----- From: "Jonathan Gordon" <[EMAIL PROTECTED]> To: "Rockbox development" <[email protected]> Sent: Tuesday, June 05, 2007 9:01 PM Subject: Re: 1 standard generic callback system > On 06/06/07, Michael Sevakis <[EMAIL PROTECTED]> wrote: > > I really think it's best to avoid a separate callback function for each > > particular things and instead just go with an interface model that groups of > > related callbacks and functions. If you want audio events, provide a pointer > > to some sort of audio events interface. Any receiver of events can just > > ignore what it doesn't care about and a tendency towards a single call with > > an event id parameter and an intptr_t parameter to pass data or pointers to > > data can keep the number of functions to a minimum. Some more specialized > > functions in the interface can be declared if needed of course. > > > > well a pointer is passed to the callbacks and it could be anything, so > this could be done, but wouldnt it make smaller code if we only ever > pass useful data? (as apposed t a struct which would have absolutly > everything?)
