[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Asko 2002-03-07 (AbstractBgVob)
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] Asko 2002-03-07 (AbstractBgVob) |
Date: |
Sat, 8 Mar 2003 21:55:40 +0200 |
User-agent: |
Mutt/1.4i |
On Fri, Mar 07, 2003 at 03:09:36PM +0100, Benja Fallenstein wrote:
>
> Hi Asko & Tuomas!
>
> Asko Soukka wrote:
> >Tuomas wants Vobs to be immutable
>
> Sounds good.
>
> > -> Bg/border properties (bgColor, drawBorder)
> > will be set when calling constructor
> > -> solids will be set by one call
> > "Colorable cloneMultiColored(Vob vob, List colors)"
>
> That method name is a bit long... but addColor() would be confusing
> (sounds like it mutates the Vob object). How about withColor() or so?
I'd really like "clone" to be part of the name, to make it obvious what's
happening. cloneColored()?
> >- I'll rewrite my PEG on monday. The new proposition will contain:
> > - Bg/border properties optionally in each Vob
>
> Even in text vobs? SolidBgVobs? Connection vobs? This doesn't sound good.
I think he meant just bg vobs.
> > - Interface Colorable, containing method to clone Vob with
> > multiple colors
> > - Abstract class ColorableVob extends Vob omplements Colorable
> > - BgVobs will be inherited from ColorableVob
>
> 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?
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".
Tuomas
Re: [Gzz] Asko 2002-03-07 (AbstractBgVob), Tuomas Lukka, 2003/03/08