gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob


From: Tuomas Lukka
Subject: Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob
Date: Mon, 10 Mar 2003 19:47:20 +0200
User-agent: Mutt/1.4i

Excellent work! I think the PEG process is working really well with
this...

On Mon, Mar 10, 2003 at 05:05:50PM +0200, Asko Soukka wrote:
> - Should Colorable Vob be immutable?
> 
>   RESOLVED: Yes. The current multi-color implementation in
>   ``RectBgVob`` and other background vobs have made them mutable.
>   Inheriting those multi-color features from Colorable Vob should turn 
> them
>   back to immutable. Immutability allows storing created vob objects,
>   re-using them and finally enhancing the overall performance.

It would be good to explain the "cloneColored" call in this resolution,
just for clarity.

> Changes
> -------
> 
> The Java classes **public interface Colorable** and **public abstract
> class AbstractColorableVob** should be created after the following
> diagram:
> 
> .. UML:: abstractcolorablevob
> 
>     jlinkpackage gzz.vob
> 
>     class Vob "abstract"
>         jlink
> 
>     class Colorable "interface"
>         methods
>           +Colorable cloneColored(List colors)
>           +List getColors()

Now that it's immutable, I'm actually leaning slightly towards Color[] colors...

> **Cell Views** and **Node Views** will be broken (and hast to be
> fixed) after this change, since background vobs' addColor interface
> will be removed to make vobs immutable.

Should explain the way they should store a prototype vob for each
node type here.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]