Re: [gzz] Abstract Colorable Vob

[Asko Soukka]

Wed, 12 Mar 2003, Benja Fallenstein wrote:
> >> I'd prefer OTOH to have colorability as an optional extra, so that
> >> no interface would expect a colorable object but check "can we color 
> >> this? If yes, do".
> Ok, but what's the return type of cloneColored() then? With interface
> ColoredVob extends Vob, it would be 'right' for all cases.

Colorable.cloneColored() can of course return only Colorable and it needs 
always casting back to ColorableVob. :/
                                                                                
> Also the case is more general: Vob should be an interface to allow
> multiple inheritance on different sub-interfaces...
                                                                                
Maybe you should PEG this, as you know the arguments?

Hmm... if Vob is an interface, we need also AbstractVob. ColorableVob 
interface would be extended from Vob interface (to allow correct return 
type for cloneColored()) and would be implemented by   
AbstractColorableVob. But what is now the relation between AbstractVob and 
AbstractColorableVob? AFAIK they won't have a relation :/

So, I don't see how this would change the situation. Still Colorable 
should be a new interface. Abstract ColorableVob would extend AbstractVob 
(that implents Vob) and implement Colorable. Again 
Colorable.cloneColored() could return only Colorable types and casting 
would be needed.

Or is it possible in Java that:
- AbstractVob implements Vob interface
- ClorableVob extends Vob interface
- AbstractColorableVob extends AbstractVob, implements ColorableVob 
  interface?

> >>>>>>>>        methods
> >>>>>>>>          +Colorable cloneColored(List colors)
> >>>>>>>>          +List getColors()
> >>>>>>>Now that it's immutable, I'm actually leaning slightly towards Color[] 
> >>>>>>>colors...
> >>>If you want to use a list when building it up, you can and call 
> >>>list.toArray

> But toArray() is an ugly construct and the user is not able to avoid 
> *that*. You could have both cloneColored(Color[]) and cloneColored(List) 
> (and potentially also, cloneColored(Color) which would seem like the 
> most practical interface of the three).

Hmm, good. cloneColored(List) could well be implemented as a shorthand for
cloneColored(Color[]). But the last one has problems:

> Is cloneColored supposed to remove the colors which are already there?!?
> I find that counter-intuitive.
 
Currently, yes. Without this, it wouldn't be possilbe to drop off colors 
from vob primitive. Again, cloneColored(Color) could be a shorthand for
getColors()+addcolor+cloneColored().

Should we have List getColorsList() in addition of Color[] getColors()?

Well, what is the relation of bgColor and solid colors? Currently 
RDFNodeView could have a following code. The problem is that I have to 
defined bgColor twice. At first as a background color, and then as solid 
color. Well, I don't know is this what we want. Tuukka said that bgColor 
and selection color should be shown at the same time.

//Creating primitives with certain bgColor
protected static ColorableVob resourceBg = new OvalBgVob(new Color(102, 
                                           255, 102), false);
protected static ColorableVob defaultBg = new RectBgVob(new Color(255, 
                                          204, 51), false);
ArrayList vobColors = new ArrayList(5);
// Adding color "selected"
if(spec.equals(cursor.getRotationNodespec(dir))) // if selected
  vobColors.add(colors.getCursorColor());
if (vobColors.size() > 0) { // Adding bgColors
  if(node instanceof Resource) vobColors.add(new Color(102, 255, 102));
  else vobColors.add(new Color(255, 204, 51));
}
Color[] colors = (Color[]) vobColors.toArray(new Color[0]);

// Finally, selecting the correct vob
if(node instanceof Resource) bg = (ColorableVob)resourceBg.cloneColored(colors);
else bg = (ColorableVob)defaultBg.cloneColored(colors);

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