in reply to Re: Tracking processing by returning objects?
in thread Tracking processing by returning objects?

So why not create a new instance each time you munge anything?

That's the approach I'd take. Each instance becomes a "result cache", with DESTROY performing cleanup where necessary.

This approach has a lot in common with functional programming: you're composing a result out of functions. The complication is that a side-effect of each function is a file-based cache that need to be managed.

Replies are listed 'Best First'.
Re: Re: Re: Tracking processing by returning objects?
by BrowserUk (Patriarch) on May 19, 2003 at 18:28 UTC

    I used the same technique for an image editor which had a similar need for caching.

    Each operation that was applied to an image, produced a new image that was the results of the previous manipulation. The buffers for the images were allocated from a built-in virtual memory manager that used an LRU caching mechanism.

    The really nice thing about the technique is it allows you to try two of three different enhancement techniques on the base image and compare them side by side before choosing which one to commit to. Also has the added bonus of making Undo a simple free current and back up to the previous version.

    That whole thing was written in a macro assembler, but it was object oriented to the point where the syntax for adding a number from memory to a register was

    esi.load Object; eax.add Object.Number;

    Thankfully, it was someone elses job to write the virtual memory manager:)


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller