[gst-devel] GstInterface

[Ronald Bultje]

Hi Dave,

On Wed, 2003-10-15 at 01:31, David Schleef wrote:
> In the third case, you have more code, and expect the app developer
> to comprehend GstInterface, and its relation to other interfaces,
> in addition to anything else.

I don't want the app developer to comprehend GstInterface. I want it to
be automated.

> I think I'm the only one that has spent the time trying to figure
> out what you're doing.  In my opinion, you are _way_ overengineering
> this, in an inappropriate way and place.  The appropriate place for
> doing something like this is in glib, and it is probably best done
> as a special kind of GInterface, not as a subclass.

Overengineering? Maybe. It's simply something I need in more than one
case, so I generalized it. I don't mind it not being part of the core,
don't get me wrong there. That said, I also don't care much about binary
size or anything - I'm not an embedded application developer. My goal is
simply to make something that will be easy for the application developer
to do. I consider this simple and logical. If each of my interfaces has
a supported() function, I'm sure I can write applications too. However,
I'd also expect many questions like "why didn't you generalize that?".

That said, your code snippets are slightly wrong. In any case, you would
always have to check the cast, since not all GstElements implement a
given interface. It will still trigger a warning + return NULL (and then
probably crash, since you didn't check for that) if I cast an avimux
GstElement to a GstMixer, even if you don't use GstInterface's trick. I
_always_ need to check the return value. In my case, I simply combine
these two into one call - that being the cast. So correctly, your code
snippet would look like:

..
if (!GST_IS_MIXER (element))
  return;
mixer = GST_MIXER (element);
if (!gst_mixer_supported (mixer))
  return;
..

And I can omit the second check because it's automated in the first
check. That's the advantage, I automate all checking into one call. I
like that. That's the _only_ reason why I did it.

Imagine I don't do it. One day, someone else will stand up that does
want to automate it into one call, since having to *always* call two
functions instead of one is annoying. We'll start with adding the
supported() virtual function to GstMixer's interface class struct; next,
we'll make automatic cast-checking like I did in GstInterface because it
saves us from having to manually check for instance-supported()ness. And
in the end, each interface will duplicate all code that is currently in
GstInterface. To *prevent* that, I "overengineered" this to be
generalized from the beginning. I don't consider that overengineering, I
simply consider that design.

You might be able to do this differently (read: easier). If so, please
propose it. But don't make an app developer make two function calls if I
can do it in one.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer