Re: [gzz] Abstract Colorable Vob

[Tuomas Lukka]

On Thu, Mar 13, 2003 at 12:13:17PM +0200, Asko Soukka wrote:
> 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?

Arhhmmm... maybe it *is* time to make Vob an interface...

> 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?

There'd be no Colorable interface then, only ColorableVob, and
its cloneColored method would return a ColorableVob.
There's also be AbstractColorableVob.

> > >>>>>>>>        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()?

We could also have cloneColorAdded()

        Tuomas