Calvin Williamson wrote:
ImageOp has exactly one output, and that output is
image data. That is the only real thing that distinguishes it. It can
have any number of inputs (The number of inputs is defined by the
particular subclass of ImageOp).
But is an ImageWriter node an ImageOp (even though it has no outputs?)
If we had ImageProducer, ImageConsumer interfaces, you still
need some class (ImageOp, or some other if you dont call it
that...) that implements the interface, and has a pointer to the
GeglImage that is produced at that node. The advantage I see
of having the producer, consumer interfaces is that if we had
two places in the class heirarchy where we needed to have the
interfaces implemented (we have no multiple inheritance
here in GObject). But I am having trouble seeing why any
op that produces just one image output cant extend from ImageOp.
In the hierarchy I suggested before, the class that just produced images
was ImageSource, the class the just consumed was ImageSink, and one that
did both was ImageFilter.
If something has more than one output, that thing would not
extend from ImageOp in the current class design. Maybe MultiImageOp.
But why is an op that produces one image special? (why does it get it's
own class?)
What are some of the methods you would put in ImageProducer and
ImageConsumer (or ScalarConsumer, PixelConsumer etc) ?
get_list_of_sources
get_list_of_sinks
attach_to_consumer
attach_to_producer
produce()
consume()
Where "x" is the approiate type, and where the attach functions can
verify that these objects are attaching to a valid type. The last two
would be useful in a threaded system, where each op is a thread.
examples for why I think this is necessary:
There are ops that have just inputs. There are ops that have just
outputs. Ops that have both input and output, though, can't be a
subclass of both the "just input" op and the "just output" op (since we
don't have multiple inheritance. Without the interface, this leads to a
duplication of code. Code to handle inputs in a "just input" op and the
same code again in a "input and output" op.
With your ImageOp abstraction above, where do you put (in the class
hierarchy) an op that produces both a Scalar and an Image (lets call it
FooOp)? If you put FooOp under ImageOp, then there is no object in the
hierarchy that declares how to work with scalar inputs (or indeed, that
the object has scalar inputs. This code could convievable be put in
FooOp itself, but what if there is more than one op that produces both
Scalars and Images?). If you were to put FooOp under the (I suppose)
ScalarOp parent class, then all the code for handling image outputs that
you currently stuck in ImageOp has to be duplicated again the the FooOp
object itself (and then agagin what if there is more than one).
Another solution to the above problem might be this:
ImageOp
ImageScalarOp
ImageScalarSampleOp
ImageScalarPixelOp
ScalarOp
ScalarImageOp
ScalarImageSampleOp
.
.
.
This would get tedious quickly, and besides, shouldn't ImageScalarOp be
congruous to ScalarImageOp?
Using interfaces solves all of these problems, even if the only purpose
of the interface is to exist (ie. to decare an associaition for an object).
--
Dan
