[gst-devel] about base classes

[Benjamin Otte]

On Fri, 18 Mar 2005, Ronald S. Bultje wrote:

> > Or did I miss something?
> [..]
> > > 2c - audio sink implementation
> > >  * format negotiation, backend setup.
> > >  Because this cannot easily be generalized without generalizing
> > >  too much, or we don't gain anything by generalizing it.
>
> Basically that part.
>
> It's not like your proposed setup is wrong and mine is right, or the
> other way around. Both are equally valid and make perfect sense. Now,
> the reason that I decided not to add backend setup (open/close) and
> format negotiation (get_format, set_format, ...) to the base class is
> because it doesn't gain us anything. It requires us to abstract
> something away without any gain (we can discuss more about this gain vs.
> no gain thing if you wish; this is only an opinion, not a fact). It's
> not like it's a lot of extra code (if any). The reason that I don't do
> it is much simpler: we're distracting the programmer from the main
> GStreamer plugin/element API for no good reason.
>
There's basically 2 reasons why I'd do it my way:

- With your design the sinkpad can't be private to the base class.
You have to set getcaps functions but must not set chainfunctions. So who
really owns the pad? The base class or the subclass? And if it's owned
half and half, where do you put the docs on which parts of the pad belong
to whom?

- It's easier to see what you have to do when you write a new subclass.
You just implement all the function stubs in the base class. No need to
know wether you must set a getcaps function, overwrite a state change
function or whatever. It's much simpler.


Benjamin