GNOME Bugzilla – Bug 503085
GstMessage should use real derived GTypes
Last modified: 2007-12-12 14:23:46 UTC
GstMessage has the concept of message types (see GstMessageType), and functions that should be used only on messages of a certain type (for instance, gst_message_parse_clock_lost()). But GstMessage derives from GstMiniObject which already has a GType. It would be easier for language bindings (and more consistent for application developers) if GStreamer had derived GTypes such as GstMessageLostClock, GstMessageWarning, etc. It's the message-type-specific functions that make this feel necessary to me. Otherwise this would be like a GError.
Same goes for GstEvent and GstQuery... not sure if it's worth adding that many new GTypes just for this bit different functionality.
I don't really see the point either. As far as I can tell, it doesn't buy you much in practice (such as compile-time checking), because you almost always get generic messages/events/queries from GStreamer which you then want to just switch() on (and cast dynamically). And the integer type field is needed in any case: for efficiency, especially in the case of queries and events, but also so you can do e.g. gst_bus_poll(bus, TYPE1 | TYPE2). An additional message-type-specific GType that's always in sync with the event type anyway doesn't seem particularly useful to me, and adding it just for the sake of consistency or elegance seems overdoing it a bit.