On Fri, Mar 14, 2003 at 06:40:49PM -0800, Daniel Rogers wrote: > > hmm, I made a mistake here. The point of having a <GeglImageConsumer> > and <GeglImageProducer> interface was that you didn't need ImageOp. > Implementing the interface is enough to show that is has image inputs > and/or outputs. I didn't like the ImageOp abstraction. ImageOp said > nothing about whether it had inputs, or output or both. Futher, what > happens when you have nodes that have two different kinds of inputs or > ouputs? Does it really belong under ImageOp, or, for example, should it > be under ScalarOp? You can't have it both ways unless one of them is an > interface. 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). 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. If something has more than one output, that thing would not extend from ImageOp in the current class design. Maybe MultiImageOp. What are some of the methods you would put in ImageProducer and ImageConsumer (or ScalarConsumer, PixelConsumer etc) ? One thing here is that it's not easy to come up with a good set of abstract classes that differentiate the ops based on the type, number, and order of its inputs and outputs. Im not against introducing producers and consumers, Im just not convinced they are useful yet. Calvin
