Daniel:
Ive just been looking at the GInterface stuff in Glib. I
didnt know that these were actually closer to what is called
"signatures" for gcc. They are kind of like Java interfaces,
but they can actually have default method implementations
as well, if I am not mistaken. I am looking at testgobject.c in
glib/gobject directory to see this.
This makes me think a little harder about your ImageProducer,
ImageConsumer interface ideas and I think I am seeing some
concrete things where these would be a good thing.
Now suppose we did have something along your lines like this:
Node
Op
Graph
AtomicOp -- (maybe move prepare, process, finish routines here)
ImageFilter -- implements ImageProducer, ImageConsumer
PointOp
Unary
Binary
etc...
AreaOp
GeometricOp
Pipe
ImageSink -- implements ImageConsumer
DisplayOp
FileOutOp
StatisticsOp
ImageSource -- implements ImageProducer
FileInOp
Color
etc, etc.
Now a couple of things make me like this more now:
1) GInterfaces can have prerequisites, so we make ImageProducer,
ImageConsumer's be Nodes, or Ops, or whatever. (I think
you mentioned this, but I didnt pick up on it then...)
2) They can actually have some default methods in them with
implementation, which I hadnt realized. At least I think so...
maybe you knew this all along, but I had not realized the
GObject interfaces worked that way...
3) Now here's what methods would work nicely if moved to ImageProducer:
(all of these are currently in ImageOp)
compute_have_rect -- computes have rects for all the output images for this op.
compute_color_model -- computes the color models for each output image
4) And for ImageConsumer:
(again this is in ImageOp currently)
compute_need_rects -- sets the need rects on all the input images.
In addition we could put your suggested "get_sources" and "get_sinks"
type methods as well of course.
Let me think about it a little more, but now I am beginning to
appreciate what we can do if we go this way. I hope I
am understanding the GInterfaces the right way...
Calvin
