

Writing a functional and yet functional image processing library in Scala - SandB0x
http://stackoverflow.com/questions/5323186/writing-a-functional-and-yet-functional-image-processing-library-in-scala

======
warrenwilkinson
Problems like this are why I only try for 'outwardly' functional code.

Without knowing the full details, I'd speculate that they only care about the
image before and after modification. So within the function, you have free
reign. For example if you just destructively modify and return a copy of the
source, to the outside caller it appears functional. And everything is
blessedly simple.

~~~
dons
> if you just destructively modify and return a copy of the source

Then the caller can no longer reference the source without observing the fact
you've mutated it -- you'd have to guarantee they've dropped all references to
the now-mutated buffer.

How do you ensure the mutation doesn't leak out like this, breaking all the
nice properties?

~~~
ricree
I think that he means the copy that gets returned is what gets destructively
modified.

In other words, the overall process winds up being functional and
nondestructive, but the intermediate internal steps aren't necessarily so.

~~~
dons
Right. You better copy the original data structure. That's one good way to
guarantee internal mutation (of the copy) isn't going to be visible. Or it
gets tricky (e.g. linear types)

