Re: [Gzz] Asko 2002-03-07 (AbstractBgVob)

[Asko Soukka]

Fri, 7 Mar 2003, Benja Fallenstein wrote:
> > I meant that if BgColor and drawBorder are just two attributes, there is 
> > no need for external AbstractBgVob. So, of course those attributes exist 
> > in only BgVobs, but they are not inherited from any template.
> ...
> I.e., the normal Java pattern.

But if we want to make vobs immutable we can't have set explicit methods, 
but all should be set by constructor :(

ColorableBgVob bg = new RectBgVob(Color.yellow, true); would create 
BgVob with yellow background and black borderline. One more attribute 
could be added for coloring the border. These border and background color 
settings wouldn't be in any abstract class (Tuomas said that these 
shouldn't be restricted). Afterwards we could create the multicolored 
version by: coloredBg = bg.cloneMultiColored(colorList);

I.e. when RDFNodeView is created at the first time, also every vob 
primitive it needs is created (one OvalBgVob without border and with green 
color, one RectBgVob without border and with yellow color). Afterwards the 
multicolored versions are cloned only when needed. 

> >>I'd prefer if the ColorableVob was the interface, extending a Vob 
> >>interface, to avoid casts (ColorableVobs could be both colorized and 
> >>added into a vob scene). Tuomas, can Vob be made an interface?
> > Tuomas did't like the word Vob in interface name, because there are no 
> > Vob interface where ColorableVob could be inherited from. 
> Re-read my last sentence :-)

:)

I was thinking on Java language level. In there, Vob is an abstract class 
and your solution would look like creating only the AbstractColorableVob. 
I admit that Colorable could be misleading name by itself, but if we look 
it in its package gzz.vob.Colorable, it could be logical.

Interface Colorable + Abstract class Vob = Abstract class 
                                           Abstract ColorableVob

?-)

-- 
Asko Soukka <address@hidden>
<http://www.iki.fi/asko.soukka/>