5 ms·

the instance of the class is a parameter to the function. As well your definition of pure is not the accepted definition. The definition depends absolutely noth

the instance of the class is a parameter to the function. As well your definition of pure is not the accepted definition. The definition depends absolutely nothing on the internal implementation as long as some in invariants hold. 1. For the given set of inputs ( including the attached object ) the output is always the same if called again with the same inputs ( including the attached object in the same state ). 2. No side effects. This means that nothing can be observed about the function apart from it's return value. If you wish to quibble as to whether the object is a parameter or not then observe that in c++23 it will be allowed an explicit this parameter to methods This is not to make the methods more pure but to enable other types of optimizations and reduce duplication of code over const and non const methods.

jb1991 4y ago
That's an odd interpretation of purity. As per the article: > A pure function only looks at the parameters passed in to it, and all it does is return one or more computed values based on the parameters... It doesn’t maintain internal state... Ideally, it isn’t passed any extraneous data If you send in an entire object state as an argument (or as an attached instance, as you argue), this is not a quintessence of functional purity and strays far from these concepts. Consider: your object can have all sorts of data in it that you are passing to every member function, and it is unlikely all that state needs to be used in every function -- as the article points out, this defeats the purpose as it's akin to passing in a big pointer to a bunch of state. In a pure function, it accepts only the specific data it needs, nothing else or extraneous, and returns a value based on these specific inputs. As I mentioned in another comment, you could say for a particular type that since it only has one data member, no harm done -- but in the general sense, most objects have more than one piece of data, and not every function needs every piece of data, so passing all that in is a sloppy approach to purity.
- injidup 4y ago
  The object state is a parameter passed to the function. The number of arguments passed to a function does not affect it's purity. The feed forward recognition phase of an LLM is pure but has billions of parameters. The purity is defined by it's behavior in relation to again. 1. Does it always return the same result for the same input parameters 2. Does it modify anything other than return a value These two properties define purity. Simple and not odd at all.
  - jb1991 4y ago
    Not sure why you are arguing about this? The issue is about the idiomatic, expected style that surrounds pure functions and functional programming. The posted article goes into this in greater detail (and more elegantly than this thread) as to why the pattern you describe -- passing a big pointer of potentially large composite data to a function (implicitly or otherwise) -- is not in the spirit of FP purity. If you want to be pedantic, you are welcome and you are academically correct, but the tradition of FP in practice is not to do this (as also pointed out in the article). It's not a question how many arguments but rather if there is extraneous data that the function does not need, as would be common with the full object.
    - injidup 4y ago
      Not sure why you are arguing about large classes with extraneous data. If this is how you program your classes and it works for you then great but honestly you should try for small immutable class where possible with pure functions ( methods). It's really liberating.
      - FpUser 4y ago
        >"It's really liberating" What IS really liberating is not being stuck to a single paradigm and let person decide which particular tool use to solve particular problem

jb1991 4y ago

That's an odd interpretation of purity. As per the article: > A pure function only looks at the parameters passed in to it, and all it does is return one or more computed values based on the parameters... It doesn’t maintain internal state... Ideally, it isn’t passed any extraneous data If you send in an entire object state as an argument (or as an attached instance, as you argue), this is not a quintessence of functional purity and strays far from these concepts. Consider: your object can have all sorts of data in it that you are passing to every member function, and it is unlikely all that state needs to be used in every function -- as the article points out, this defeats the purpose as it's akin to passing in a big pointer to a bunch of state. In a pure function, it accepts only the specific data it needs, nothing else or extraneous, and returns a value based on these specific inputs. As I mentioned in another comment, you could say for a particular type that since it only has one data member, no harm done -- but in the general sense, most objects have more than one piece of data, and not every function needs every piece of data, so passing all that in is a sloppy approach to purity.

injidup 4y ago
The object state is a parameter passed to the function. The number of arguments passed to a function does not affect it's purity. The feed forward recognition phase of an LLM is pure but has billions of parameters. The purity is defined by it's behavior in relation to again. 1. Does it always return the same result for the same input parameters 2. Does it modify anything other than return a value These two properties define purity. Simple and not odd at all.
- jb1991 4y ago
  Not sure why you are arguing about this? The issue is about the idiomatic, expected style that surrounds pure functions and functional programming. The posted article goes into this in greater detail (and more elegantly than this thread) as to why the pattern you describe -- passing a big pointer of potentially large composite data to a function (implicitly or otherwise) -- is not in the spirit of FP purity. If you want to be pedantic, you are welcome and you are academically correct, but the tradition of FP in practice is not to do this (as also pointed out in the article). It's not a question how many arguments but rather if there is extraneous data that the function does not need, as would be common with the full object.
  - injidup 4y ago
    Not sure why you are arguing about large classes with extraneous data. If this is how you program your classes and it works for you then great but honestly you should try for small immutable class where possible with pure functions ( methods). It's really liberating.
    - FpUser 4y ago
      >"It's really liberating" What IS really liberating is not being stuck to a single paradigm and let person decide which particular tool use to solve particular problem