4 ms·

How is it syntactic sugar? In the second version the function is now accessing an argument rather than something outside its scope. That's pretty much the defin

• seanwilson 11y ago
  I would agree if getName was accessing a global variable but I don't see how getName(person) is any more functional than person.getName(). OCaml features objects with similar syntax for example: http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.html http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.ht...
  • typon 11y ago
    Because you can write person.getName() like this: def getName(): . . this.setName('foo') . . return this.name There's nothing in principle preventing you from doing that in the "functional" approach but if your data is immutable then you can't do it.
    • Someone 11y ago
      def getName(person): person.setName('foo') return person.name The problem, from a functional viewpoint, isn't the implicit argument, it is the fact that you can write setName.
      • typon 11y ago
        Really? I thought implicit arguments were a strict no-no in functional programming.
        • Someone 11y ago
          Implicit arguments are still arguments. It is just syntactic sugar, and I think syntax changes cannot change a functional language into a non-functional one.
  • chchrutuch 11y ago
    It's not and anyone arguing to the contrary is wrong. The article is way off base on this. You could argue it's purely syntactic sugar, but really, it's barely even: it's just alternate syntax. People arguing against this are failing to understand that different languages have different syntaxes. person.getName() is the same as getName(person). In the former it's an implicit parameter, in the latter it's explicit. Or, looking at it differently, one is a syntax for functional calls that prepends the first argument as a target, and one is a syntax that accepts the target as the first argument. With Java 8 method references, you can see this a bit more clearly. You could, for instance, do this to get a function without the implicit this: Function<Person, String> getName = Person::getName; getName.apply(new Person());
• chchrutuch 11y ago
  It's alternate syntax, or, if you want to go there, you can say it's syntactic sugar. Take a few minutes to go read the bytecode Java generates on something like person.getName() to see how this is being handled at that level. Further, purity is about expectations, not scope. Expecting something to be pure means I can reliably call it with the same arguments and always get the same result, with the additional expectation that it will change nothing about the world. A function that accepts no arguments can be pure but must always return the same thing. If the person's name is indeed immutable, then person.getName(), provided it performs no side effects, is perfectly pure. In concept, other than brevity, invoking a constructor on an immutable object is not much different than the function returned by a higher order function such as this: (defn name-getter [{name :name}] (fn [] name)) (def get-name (name-getter {:name "John"})) (get-name)