Hacker News Reader

Comment by jasim | Hacker News Reader

Two interesting ideas that helped me get insight into OO:

1) An object is a poor man's closure; and a closure is a poor man's object.

2) Most object-oriented programming is done with mutable state, which muddles what OO is. You don't really need state to have objects.

In a closure, the lexical scope is preserved, and the functions defined in it can access it any time. This is very similar to what an object does: https://stackoverflow.com/a/2498010

When objects are immutable, one gets to truly appreciate the elegance of grouping both data and their functions together: https://dev.realworldocaml.org/objects.html#scrollNav-3

View on HN

RE 2 do you mean you don't need to have mutable state to have objects? Unless I have a huge misunderstanding of what you mean by 'state', it seems like state is necessary for objects to exist..

I think the grandparent comment is saying that you do not need your state to be mutable; that writing software where your state is immutable is useful and elegant.

Yeah that is what I was trying to clarify, I guess my comment was equally confusing because I am getting responses trying to fill in words that the OP may or may not have left out accidentally

One book[1] I read explained this in detail, amongst other similar concepts. It was really interesting and helped me think of how functional concepts could work in OOP languages.

1: https://www.elegantobjects.org/

I agree with a lot of those suggestions, but I am still scratching my head at what it means to have "objects with no state", at that point it seems like we just have static methods that are in some namespace which is the object. Having immutability does not get rid of state existing.

Objects do have state, but they can be either mutable or immutable. The link in my original comment describes an immutable stack (written in OCaml, but is fairly readable) where both push and pop returns a new stack object. The original object is never changed. In a mutable stack, push would return void (or unit in OCaml), which signifies a side-effect. pop would return the element, and the object changes in-place.

Yeah, I'm familiar with the pattern, but I wouldn't say that this is a 'stateless' pattern because even having that object is 'state'. I don't think 'stateless' makes sense if objects are involved. I would agree that it's immutable.

> Even having that object is state.

There is mutable state on the conceptual level, i.e. what is modelled, but not on the language level abstraction of an object.

There is no mutable data/state on the language level, at least how things are understood in pure functional programming. But of course mutable state in the real world (for lack of a better term) can still be modeled there.

You don't. See http://wcook.blogspot.com/2012/07/proposal-for-simplified-mo... by William Cook. However, objects help to tame mutable state.

Can you point me to a language or some code snippets with objects with no state --- in my head this just comes back to some sort of namespace for static functions. At that point, you need no object, so what's the point of having one. If you are saying that having a reference to an object is not 'state' then OK, but that makes no sense to me. I'm not trying to be pedantic, just trying to understand if OP had a typo or there is a whole world out there that I can't conceive of.

IMO that post is specifically calling out the mutable part, not claiming to have objects completely without state.

Again, in discussions like this state is often used to refer to mutable state (an identical thing itself mutates).

Having a conceptual reference (oh god another overloaded term) to something does not imply that there is mutable state on the programming language as long as the reference is immutable.

    def times(x, y)
      if x.is_one?
        y
      elsif x.is_zero?
        x
      else
        y.add(times(x.decrement, y)
      end
    end

a) x and y are not mutated. b) you can implement the called methods on various immutable object types, and the code would work (assuming we send in the same types, and they obey certain protocols but that is yet another different concern):

    class WeirdString
      def init(v)
        @val = v
      end

      def val
        @val
      end

      def is_zero?
        @val.empty?
      end

      def is_one?
        @val.length == 1
      end

      def decrememt
        WeirdString.new(@val[0..-2])
      end

      def add(ws)
        WeirdString.new(@val + ws.val)
    end

    # times(WeirdString.new('abc', 'hi').val → 'hihihi'

Now, you may say the fact that the object has an instance variable means there is state and you'd be right depending on how you define state, but at any rate the state of a given instance of WeirdString is not mutable.

If that's what you mean by "no state", then I misunderstood, but I don't especially care what you call a namespace for static functions. (A module?) I use immutable objects frequently, and they're a different thing, just as first-class nested functions are a different thing from standard C functions.

I think "state" is simply an overloaded term and that causes misunderstandings here. I believe by "state" GP meant specifically mutable state on the level of the programming language abstraction.

"Having state" often implies mutability, i.e. to be in a given state means the same thing can be in different states/configurations as well.

On the other hand people often also use the word "state" to refer simply to a "current state" of something at a given time, and then under this interpretation there is state in immutable objects.

As you already know, "representing (real world) state at some step/time" does not require mutability on the language level. These immutable objects are state snaphots of a hypothetical mutable object. Operations on them cannot mutate them, but instead derive a new snaphot that represents the new state at a given time after the operation. So working with those snapshot does represent state and state changes and models real world state, but the individual snaphots/immutable objects cannot be mutated.

Whether those immutable objects deserve the monicker "object", I don't really have a opinion on, but I wouldn't outright deny it.

Are they useful in similar ways that mutable objects are? I'd say so.

Immutable objects can still get you polymorphism/subtyping and encapsulation, features often ascribed to object oriented programming.

"Objects" in OOP, as in "let's couple data with behavior" necessarily means mutable state, otherwise they are just types. Use only immutable data; write abstract classes only; do polymorphism with interfaces and you'll end up with something very similar to what people mean by 'type-level programming' in Haskell.

Reply on news.ycombinator.com