Not really - having each function do a precise task is a general good practice, not a quality of pure functions. A setter, for example, is an impure function that does a precise task.
I converted the array to an object, but the function is still pure(or, more precisely, can be pure - I didn't write Obj.__init__'s body and Python does not guarantee function purity). We still have the original array - we did not change existing values, only returned new ones.
A better example will adding an element to an array:
FP is not about eliminating side effect at all, because a software that does not has any side effect has no use at all. Instead, FP is about making as much area of your code to be pure function so that they are predictable and consistent, while allow only specific module to be impure, i.e. having side effect.
I would think so, yes. You find that most Smalltalk-inspired OOP advocates tend to view sharing of data as a bad thing. Instead, data is private to an object, and you just tell the object what you want it to do (by sending it a message or invoking a method). The object then induces local mutations to itself. It's still not technically a pure function, but this flavor of OOP follows the spirit of not mutating a shared external state. Because that's what makes programs hard to change over time.
A pure function has additional benefits like thread safety.
Not really - having each function do a precise task is a general good practice, not a quality of pure functions. A setter, for example, is an impure function that does a precise task.
Ok, but you sometimes NEED to do impure function no ?
How could you not change the type of some variables ?
Ex :
You want to get array data to convert into object, you need to do an impure function no ?
Not really:
I converted the array to an object, but the function is still pure(or, more precisely, can be pure - I didn't write
Obj.__init__
's body and Python does not guarantee function purity). We still have the original array - we did not change existing values, only returned new ones.A better example will adding an element to an array:
foo
is impure, because it changes an existing value.bar
is pure, because it does not change an existing value - it creates a new one.Now I got it !
Last question, why do we have to do this ?
FP is not about eliminating side effect at all, because a software that does not has any side effect has no use at all. Instead, FP is about making as much area of your code to be pure function so that they are predictable and consistent, while allow only specific module to be impure, i.e. having side effect.
.. So, pure function could also be a priority for OOP no ?
I would think so, yes. You find that most Smalltalk-inspired OOP advocates tend to view sharing of data as a bad thing. Instead, data is private to an object, and you just tell the object what you want it to do (by sending it a message or invoking a method). The object then induces local mutations to itself. It's still not technically a pure function, but this flavor of OOP follows the spirit of not mutating a shared external state. Because that's what makes programs hard to change over time.
A pure function has additional benefits like thread safety.
Ahah thread.. I'm doing PHP :(