Re: [gzz] Abstract Colorable Vob

[Tuomas Lukka]

On Sun, Mar 16, 2003 at 12:24:37PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >On Sat, Mar 15, 2003 at 05:50:27PM +0100, Benja Fallenstein wrote:
> >>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...
> 
> Well, I would use "new FooVob(x, y)" rather than "clonePosition(x, y)". 
> The only use case I see for cloneColorXXXed (as opposed to e.g. new 
> OvalBgVob(colors)) is that you create a new vob, pass it around to a few 
> methods which may or may not add their own colors, and then render it on 
> the screen. For this, cloneColorAdded is useful and cloneColorReplaced 
> doesn't seem to make much sense.
> 
> Again, could you please give a use case that needs cloneColorReplaced()?

The point is that we want to avoid creating lots of new objects for performance
reasons. The reason we had to have vob factories for the backgrounds
was that the cell bg vobs were mutable.

Now that they're immutable, we can use *prototypes* (the design pattern):
just put in a vob from which you clone the things.

To make things clearest, the idea is that the cloneWithColors is the method
that creates the new vob with the right colors for this one thing.
The default bg color is already in the prototype vob.

I can see that my points would make no sense without the above idea ;)

Ok?

        Tuomas