Andreas Beck wrote:
>
> Ah - here it is ... threaded mailreaders have disatvantages *g*.
>
> > While we are at it we might as well create giiSplitInputs/ggiSplitInputs
> > such that a visual can yank its original input back out of a join,
> > rather than being forced to abandon it entirely.
>
> I see. Good idea. As long as one can easily detach _all_ inputs from a
> visual and attach them to another one, all is well.
that kind of reminds me of an old argument I brought up here on this list
months ago, which is known in (OO) software engineering as the 'interface
segregation principle':
if 'input' and 'visual' are two related but separate entities (as you
state clearly in your message), why do you deal with them in a single
object (ggi_visual) in the first place ? Why not have the 'visual modulus
input' as the real fundamental type (this then is a 'Drawable'), and let
a 'visual' just be the tuple (drawable, input). That sounds much more simple
and clean to me.
Note: no, I'm not proposing any changes like this for this release.
Regards,
Stefan
