Re: Combining mutable objects with const references

anonposting@[EMAIL PROTECTED]
 writes:

> On Apr 23, 4:24 pm, Joachim Durchholz <j...@[EMAIL PROTECTED]
> wrote:
>
>> That depends.
>> If efficiency is your goal, then you're probably right. But then you
>> probably should be coding in assembly.
>> If maintainability is your goal, then you're probably not right.
>
> The kind of object use I am refering to is not optimization. Suppose
> my object is a car in a game and its position (my point p) changes
> every time the game engine calculates a new position for the car. Of
> course we would not create a new car object every twenty milliseconds.
> Every time an imperative programmer destructively updates an object,
> he is using an object whose previous values he knows he will not have
> to refer to later. So these types of object are very common.

Modern games do not modify selecetd parts of the picture on the screen
but instead create a new picture every frame.  So it would only be
natural to create a new "scene" in memory and display that instead of
destructively updating the old scene.  This will also allow for
rewinding or replaying parts of a game (as some games allow).  If a
large part of the scene is shared between frames, this doesn't have to
take enormous amounts of memory.

Where you do not need to rewind or restore, destructive updating can
be seen as an optimisation, but by using almost identical programming
constructs (differing only in type or small annotations) for creating
new objects and destructively updating old objects, it will be a lot
easier to add rewind facilities afterwards.

	Torben