[gst-devel] gst-python and queues

[Thomas Vander Stichele]

On Fri, 2004-08-27 at 12:52, Johan Dahlin wrote:
> > I think for the API it's a lot better to
> > s/gst_element_factory_make/gst_element_new/ since that's more or less what
> > people would expect. (The same goes for schedulers or everything else
> > that's provided by factories.) It somehow makes more sense, doesn't it?
> 
> Well, gst_element_factory_make is not strictly a constructor of
> GstElement. I think that the requirement of a constructor for an object
> in an object oriented language should return the type of the created
> object and not something that is a subclass of it.

Yeah, in OO it's also called a factory, probably hence the name.  Ie, a
factory is an object that can instantiate other objects from different
classes.

> But I must say that gst.Element('mad') is quite nice syntax even though
> it breaks the object-oriented paradigm.

... but I think that this is more important.  Especially in python,
where there's not really a distinction between "object reference as a
superclass" or "object reference as a subclass", I don't see the problem
with doing this, since the object returned by gst.Element() is in fact a
GstElement.

There are other liberties taken in the python bindings, because python
is more expressive and it's thus possible to combine several C methods
in one python function; since those liberties are taken anyway with the
purpose of making it nicer to program in, I personally feel we should
keep the constructor syntax.

But in the end it's the maintainer's call :)

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If only you'd come back to me
If you laid at my side
wouldn't need no mojo pin
to keep me satisfied
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/