Re: [gzz] Abstract Colorable Vob

[Benja Fallenstein]

Tuomas Lukka wrote:
> 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.

Ok, good.

> 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?

Hmm.

I think it usually makes sense to require that the prototype vob has no 
solid colors: The common situation is,

    vob = prototype;
    if(something)
        vob = vob.cloneColorAdded(Color.yellow);
    if(somethingElse)
        vob = vob.cloneColorAdded(Color.blue);

If it is at all *possible* that the prototype includes solid colors of 
its own, this would have to be something like,

    vob = prototype.cloneColorReplaced(new Color[0]);
    if(something)
        vob = vob.cloneColorAdded(Color.yellow);
    if(somethingElse)
        vob = vob.cloneColorAdded(Color.blue);

I.e., if we do not want *any* solid colors on the vob, we would still 
have to create a new vob object(!).


*If* we allow solid colors on the prototype--

May we want to do this: The prototype vob has a list of solid colors, 
but we want to have *different* ones on the final vob?

May we want to do this: The prototype vob has a list of solid colors, 
and we want to have *those and additional others* on the final vob?

I do not see a use case for the first, but can imagine one for the 
second. Let's say we have lots of clones, shown as yellow, but few 
accursed cells, shown as blue, in a scene. Now we could write:

    if(isClone)
        vob = clonePrototype; // yellow solid
    else
        vob = normalPrototype; // no solids

    if(isAccursed)
        vob = vob.cloneColorAdded(Color.blue);

I couldn't use cloneColorReplaced() now without overwriting the color 
from the prototype.


I see where you going, but I'm not yet sure that cloneColorReplaced() is 
really a good idea-- so far, it seems to me that even with prototypes, 
cloneColorAdded() works better.

You said that you think cloneColorAdded() is like addToX(float), but I 
think that this is different because a) you know what 'x' you start with 
('no colors'-- or else you have strange behavior anyway, for the nodes 
rendered without changing the colors), and b) the usual pattern actually 
*does* make you 'add' things (if(a) add(A); if(b) add(B); etc.).

- Benja