5 ms·

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

by tudelo 7y ago

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..

lelandbatey 7y ago
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.
- tudelo 7y ago
  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
derblitzmann 7y ago
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/ https://www.elegantobjects.org/
- tudelo 7y ago
  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.
  - jasim 7y ago
    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.
    - tudelo 7y ago
      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.
      - quelltext 7y ago
        > 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.
abecedarius 7y ago
You don't. See http://wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html http://wcook.blogspot.com/2012/07/proposal-for-simplified-mo... by William Cook. However, objects help to tame mutable state.
- tudelo 7y ago
  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.
  - al2o3cr 7y ago
    IMO that post is specifically calling out the mutable part, not claiming to have objects completely without state.
  - quelltext 7y ago
    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.
deleted 7y ago
[deleted]
quelltext 7y ago
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.

by tudelo 7y ago

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..

lelandbatey 7y ago

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.

tudelo 7y ago
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

derblitzmann 7y ago

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/ https://www.elegantobjects.org/

tudelo 7y ago
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.
- jasim 7y ago
  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.
  - tudelo 7y ago
    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.
    - quelltext 7y ago
      > 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.

abecedarius 7y ago

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

tudelo 7y ago
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.
- al2o3cr 7y ago
  IMO that post is specifically calling out the mutable part, not claiming to have objects completely without state.
- quelltext 7y ago
  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.

deleted 7y ago

[deleted]

quelltext 7y ago

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.