gzz-dev
[Top][All Lists]
Advanced

[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




reply via email to

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