gzz-dev
[Top][All Lists]
Advanced

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

Re: [gzz] Abstract Colorable Vob


From: Tuomas Lukka
Subject: Re: [gzz] Abstract Colorable Vob
Date: Sun, 16 Mar 2003 09:02:07 +0200
User-agent: Mutt/1.4i

On Sat, Mar 15, 2003 at 05:50:27PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >On Fri, Mar 14, 2003 at 11:32:25AM +0200, Asko Soukka wrote:
> >
> >>Hmm... Benja wants that the default action is adding colors next to the 
> >>colors of the original Vob. So, following shouldn't replace the existing 
> >>colours.
> >>
> >>   ColorableVob cloneColored(Color[])
> >>   ColorableVob cloneColored(List);
> >>   ColorableVob cloneColored(Color);
> >
> >
> >I disagree; cloneColored sounds to me like "clone this, but with these 
> >colors".
> 
> To me, the opposite-- "clone this, but with these *new* colors." So if 
> we call that cloneColorAdded, the other case should be cloneColorReplaced.

I can live with that.

> My interpretation may be partly due to the fact that I do not see a use 
> case for cloneColorReplaced. I asked for this before: Can somebody give 
> me one?
> 
> In cloneColorAdded, we do not know whether another party has previously 
> added other colors, we just do our job. In cloneColorsReplaced, we 
> assume that somebody else may have added colors we want to remove before 
> adding ours, and that nobody else has added colors we do not want to 
> remove. When would this be the case?

It makes it easier to know where you are. To me, the alternative
is like having a "addToX(float)" instead of "setX(float)" for a float field...

        Tuomas




reply via email to

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