Re: [Subhandler-devel] Some ideas for architecture

[Julio S. <jsa...@us...>]

El s=E1b, 25-10-2003 a las 13:48, Laurent Pinchart escribi=F3:

> So basically you're reimplementing GObject from the glib ?

No at all, GObject is much more ambitious.  If I had the most remote
thoughts of reinventing that, I would leave for C++ right away.

I have just defined a minimal set of conventions and macros that help in
writing the different modules.  Deliberately I want to avoid going
overboard with it.  This project is not about building object-oriented
frameworks.

What about using GObject?  I am not sure what to think of it.  I have
the feeling that either I did not understand its purpose or that their
desire to avoid C++ took them too far.  In other words, if GObject is
the answer, I probably did not understand the question.

Is there a sample, small application or tutorial, that showcases its
use?  Everytime I read the reference documentation I feel overwhelmed and
I don't feel it like something I would willingly use.

> Why do we need to store pointers to the class and instance methods in the=
=20
> class object instance ? Can't we call the methods explicitely like in=20
> glib/gtk+ ? Only pointers to the virtual methods must be stored in the cl=
ass=20
> object instance.

Economy of concepts.  Since virtual functions are unavoidable, we treat
them all like that for implementation purposes.  Calling the functions
directly require, except from the same class, name mangling that we get
rid of too this way.  Notice that this is nothing like GObject, the
object model is implemented mostly by syntactic sugar, no run-time
evaluation of inter-class relationships (the model is "early binding").=20
So the ability to call a method depends on its syntactic visibility and
it is determined at compile-time, this provides a limited type-checking
at compile-time that avoids some mistakes.

In fact, I do not see an easy way to have correct inheritance of classes
that are not accessed by pointers (I cannot even imaginge how C++
achieves it).  I see no problem in accesing methods directly from the
class they are defined in.  It's good for private methods that are not
meant to be visible or refinable: it let us hide their definition.  But
going beyond that requires special-casing public methods and having a
different calling convention for each.

Again, this has to be simple to use and maintain.  If this goes too far,
I think we are better off moving to C++.

> I don't like the idea of having an initialized field in the class. Wouldn=
't it=20
> be better to use an accessor function ? Something like

Good idea, consider it done.  I mean it, it is already in. I implemented
your suggestion and has made the thing cleaner.  Before that, the class
had to be a global struct (since it was needed everywhere).  Now it is
hidden.  We incur the cost of an additional function call everytime a
class method is invoked, but there is a benefit for it.

On the other hand, I have found that class initialization requires some
thinking.  Let me explain why initialization there is not sufficient.

Suppose a program that reads input in an unknown format and produces
output in some other format.  Say:

	subhandler -i input.srt -o output.sub -oformat microdvd \
		--timeshift=3D+34s

where we want to convert from SRT to MicroDVD format while correcting
the time of each subtitle by 34 seconds.  There has to be a way to
create an object of a class chosen from a set of possibilities we do not
know beforehand and that tne choice can be somehow described with a
string (like --oformat above or maybe some kind of URL, MRL or similar)
or determined from the data itself.

Hardwiring the set of choices makes subsetting difficult, so each format
has to register somehow its presence (e.g. it could provide a set of
file extensions understood, a pattern to look for in the input or some
other selector method plus some constructor that would return an object
of the that class).

I have a similar case with demultiplexing subtitles where I did not want
to hardwire the set of substream types that can appear inside an MPEG
stream.

Forgive me for not elaborating this further, suffice to say that there
is the need of making an initialization call per class and that doing it
at the accessor is too late.  That initialization call can be combined
with _init_class, but it could be kept separate.  In any case, the
program may need to make a call to initialize_subhandler or somesuch
that I find regrettable.  Is there any method to have something called
at program start time in C?  In Ada this would be trivial, though.  Even
Perl would make this easy.

> about defining wrapper methods to them ? We could even inline the wrapper=
=20
> methods.

I am not sure to understand what you suggest.  Those wrapper methods,
how would they be named?  I mean, if I have a virtual method called
destroy and I have and object obj, what would be the syntax to call that
method?  And how would it be implemented?

> I don't have a lot of experience with gtk+, so I don't really care, but I=
=20
> think that it will be easier to attract developpers if we stick to a the =
gtk+=20
> coding rules.

So can you suggest a naming scheme for classes?  Just dropping
underscores?  Or should we reorder things in the process?  For instance,
how would you rename the following classes?

	Subhandler_IO_MPEG
	Subhandler_Subtitle_Bitmap
	Subhandler_Stream_CVD

I'd like to get this settled soon, since I do not want to start
committing to CVS with names that are *known* to change.

Regards,

Julio