Re: [gzz] Abstract Colorable Vob

[Asko Soukka]

Mon, 17 Mar 2003, Tuomas Lukka wrotei:
> On Sun, Mar 16, 2003 at 07:50:36PM +0100, Benja Fallenstein wrote:
> > I think it usually makes sense to require that the prototype vob has no 
> > solid colors: The common situation is,

And with current plans, I don't see it reasonable to add solid colors 
in constructor. (Only pure constructor ColorableVob(Color[] colors) 
seems to be possible, and it won't make much sence, since no parameters 
could be sent to the current background vob's contructor). 

Well, of course a prototype could be still made with cloneColorXXXX method.

> > You said that you think cloneColorAdded() is like addToX(float), but I 
> > think that this is different because a) you know what 'x' you start with 
> > ('no colors'-- or else you have strange behavior anyway, for the nodes 
> > rendered without changing the colors), and b) the usual pattern actually 
> > *does* make you 'add' things (if(a) add(A); if(b) add(B); etc.).
> 
> What color is the vob if there's no solid colors?

:)

Benja: How should this work with RDFNodeView in Loom? Do you want that 
the different bgColors in it (yellow for literals, green for resources) 
will be handled as solid colors and shown splitted with e.g. mark color?

> This would work if there were another attribute for the color
> if there's no solid colors...
> I still do want both functions; if for nothing else, for plain *control*
> of the attribute.

Or for this naming conversation. Should we have the method cloneColors() 
at all, since we don't reach any consensus about it? I can't say for 
myself. Bare cloneColor() sound cloneColorReplace() for me, but I agree 
that cloneColorAdded() could probably have more use.

But a bad thing would be that cloneColorAdded() could be used easily 
wrong. Instead of collecting solid colors at first into List or Color 
array, someone could use cloneColorAdded for every single new color.

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