6 ms·

Your definition of an object is similar to one that I’ve used[1][2][3], which is unsurprising since we got it from the same place. But, now I define an object

Your definition of an object is similar to one that I’ve used[1][2][3], which is unsurprising since we got it from the same place. But, now I define an object as any component with which you interact strictly by way of negotiation (as opposed to command and control), and I finally think I understand why Alan Kay says that the most important thing in OOP is the message passing. Thus, statically-typed languages like C#/Java/C++/etc. are also capable of being object-oriented as long as you avoid setters and realize that some of the negotiation happens at compile-time. [1] https://news.ycombinator.com/item?id=8679224 https://news.ycombinator.com/item?id=8679224 [2] https://news.ycombinator.com/item?id=11967631 https://news.ycombinator.com/item?id=11967631 [3] https://news.ycombinator.com/item?id=11809477 https://news.ycombinator.com/item?id=11809477

betenoire 9y ago
Avoid setters?
- lacampbell 9y ago
  Not parent, but I think setters destroy what's objecty about objects - that you send them high level messages and don't care what's inside of them. As Alan Kay puts it (paraphrasing): "setters turn an object back into a data structure"
  - eropple 9y ago
    This is one of the few things about Ruby idioms that drive me a bit nuts--improper use of `attr_accessor` when `attr_reader` creates better and cleaner code is one of the leading code smells in the library ecosystem.
    - cagmz 9y ago
      Is this to say that `attr_accessor` is too "heavy handed" when just using `attr_reader` could have sufficed?
      - eropple 9y ago
        It's not about heavy-handedness, it's that `attr_accessor` breaks encapsulation of private state and code very rarely takes into account what actually updating that member variable does. It's used mostly because novice Rubyists are told that that's how you make a variable accessible, not that that's how you make it read-writable. In C#, on the other hand, when you create a property that's the moral equivalent, there's a lot more of a focus on creating getter-only properties that reveal state but don't let you munge it. Ruby is also pretty bad about using #freeze and #taint, but the latter is a lost cause.
  - scarface74 9y ago
    What's the difference between a setter in languages like C# and any other method call? I agree that if you class Foo with a property: public string Bar {get; set; } and used as: foo.Bar = "baz" It does look like just another data structure. But what's the difference between that and having a method: public void setBar(string value) { _bar = value; } It is just as easy to add logic to the property later on: public string Bar{ get{ return _bar; }; set { ...some logic; _bar = value; } As it is: public void setBar(string value) { ..some logic; _bar = value; } In fact, they both compile to roughly the same thing.
    - dllthomas 9y ago
      I'd call that "still a setter". I think the concern is that if bar is more about the representation of the object than the behavior, you're not operating at the right level of abstraction.
      - scarface74 9y ago
        And the other alternative, because an object still usually needs some type of values would be: class Foo { Foo(string bar) { _bar = bar; } //Foo is the constructor } The benefit being that once an object is created, it is guaranteed to be in a valid state. But by classical OO an object represents state + behavior. So why not do both? Assign the value in the constructor to guarantee that the object is always in a valid state and use a property (if the object is an entity as opposed to a value object), when it needs to change?
        lacampbell 9y ago
        Why is it changing? have the method name reflect that domain reason, not reflecting the mechanical details of which internal fields need to change.
      - dragonwriter 9y ago
        The thing is, in simple cases the implementation will trivially parallel the sensible interface. So setters are appropriate. The problem becomes using setters where that's not the case, often to support tooling that is dependent on constructing objects from serialized state (which often also involves the same kind of abuse of getters, to which exactly the same concerns apply.)
- Ace17 9y ago
  Obligatory Casey Muratory rant: https://www.youtube.com/watch?v=_xLgr6Ng4qQ https://www.youtube.com/watch?v=_xLgr6Ng4qQ
lacampbell 9y ago
But, now I define an object as any component with which you interact strictly by way of negotiation (as opposed to command and control), and I finally think I understand why Alan Kay says that the most important thing in OOP is the message passing. That's actually a really good, concise definition. I might use this in future bikesheddings.
jakobegger 9y ago
I'm not sure what's the problem with setters? In my eyes, they are just a convenient shorthand for a common message. For example, Objective-C before version 2.0 didn't have setters; so the libraries had lots of methods like "setTitle:", "setDelegate:" etc. Setters are just a convenient shorthand. And in ObjC and in Swift (I don't know Java/C#/C++ so well) you can override setters to do whatever you like, so there really isn't much of a difference between using a setter and sending a message -- it's just syntactic sugar that makes code more readable.
- noblethrasher 9y ago
  By “setter”, I mean a mechanism by which code that is external to an object can gain unmediated access to one or more of the object’s mutable instance variables. The big idea is that the sender should not be able to assume that the message, `setFoo`, will have any particular effect with respect to the reciever’s state.
  - probablybroken 9y ago
    It sounds like you are referring to public properties.
  - justincormack 9y ago
    In languages like Lua you can always mediate what look syntactically like setters.
  - DougBTX 9y ago
    At least in C# terminology, a "setter" for a public property is mediated access, unmediated access would be a public field that can be set without invoking a setter method. Getters and setters in C# are method calls, like `setFoo` in Java, so can't be assumed to be simple, they can do anything any other method can do.
    - noblethrasher 9y ago
      As it turns out, C# is a language that I know extremely well; I'm aware that setters can have arbitrary code. But, here's the problem: A programming a language is medium for thought, which means that it promotes or prevents the occurrence of certain ideas. So, even though the compiler will accept any legal void-returning code within the inner braces of public Foo Bar { set { //Do stuff } } The fact that the client code is going to look like `Obj.Foo = whatever` will practically foreclose on all but a small subset of possibilities.

betenoire 9y ago

Avoid setters?

lacampbell 9y ago
Not parent, but I think setters destroy what's objecty about objects - that you send them high level messages and don't care what's inside of them. As Alan Kay puts it (paraphrasing): "setters turn an object back into a data structure"
- eropple 9y ago
  This is one of the few things about Ruby idioms that drive me a bit nuts--improper use of `attr_accessor` when `attr_reader` creates better and cleaner code is one of the leading code smells in the library ecosystem.
  - cagmz 9y ago
    Is this to say that `attr_accessor` is too "heavy handed" when just using `attr_reader` could have sufficed?
    - eropple 9y ago
      It's not about heavy-handedness, it's that `attr_accessor` breaks encapsulation of private state and code very rarely takes into account what actually updating that member variable does. It's used mostly because novice Rubyists are told that that's how you make a variable accessible, not that that's how you make it read-writable. In C#, on the other hand, when you create a property that's the moral equivalent, there's a lot more of a focus on creating getter-only properties that reveal state but don't let you munge it. Ruby is also pretty bad about using #freeze and #taint, but the latter is a lost cause.
- scarface74 9y ago
  What's the difference between a setter in languages like C# and any other method call? I agree that if you class Foo with a property: public string Bar {get; set; } and used as: foo.Bar = "baz" It does look like just another data structure. But what's the difference between that and having a method: public void setBar(string value) { _bar = value; } It is just as easy to add logic to the property later on: public string Bar{ get{ return _bar; }; set { ...some logic; _bar = value; } As it is: public void setBar(string value) { ..some logic; _bar = value; } In fact, they both compile to roughly the same thing.
  - dllthomas 9y ago
    I'd call that "still a setter". I think the concern is that if bar is more about the representation of the object than the behavior, you're not operating at the right level of abstraction.
    - scarface74 9y ago
      And the other alternative, because an object still usually needs some type of values would be: class Foo { Foo(string bar) { _bar = bar; } //Foo is the constructor } The benefit being that once an object is created, it is guaranteed to be in a valid state. But by classical OO an object represents state + behavior. So why not do both? Assign the value in the constructor to guarantee that the object is always in a valid state and use a property (if the object is an entity as opposed to a value object), when it needs to change?
      - lacampbell 9y ago
        Why is it changing? have the method name reflect that domain reason, not reflecting the mechanical details of which internal fields need to change.
    - dragonwriter 9y ago
      The thing is, in simple cases the implementation will trivially parallel the sensible interface. So setters are appropriate. The problem becomes using setters where that's not the case, often to support tooling that is dependent on constructing objects from serialized state (which often also involves the same kind of abuse of getters, to which exactly the same concerns apply.)
Ace17 9y ago
Obligatory Casey Muratory rant: https://www.youtube.com/watch?v=_xLgr6Ng4qQ https://www.youtube.com/watch?v=_xLgr6Ng4qQ

lacampbell 9y ago

But, now I define an object as any component with which you interact strictly by way of negotiation (as opposed to command and control), and I finally think I understand why Alan Kay says that the most important thing in OOP is the message passing. That's actually a really good, concise definition. I might use this in future bikesheddings.

jakobegger 9y ago

I'm not sure what's the problem with setters? In my eyes, they are just a convenient shorthand for a common message. For example, Objective-C before version 2.0 didn't have setters; so the libraries had lots of methods like "setTitle:", "setDelegate:" etc. Setters are just a convenient shorthand. And in ObjC and in Swift (I don't know Java/C#/C++ so well) you can override setters to do whatever you like, so there really isn't much of a difference between using a setter and sending a message -- it's just syntactic sugar that makes code more readable.

noblethrasher 9y ago
By “setter”, I mean a mechanism by which code that is external to an object can gain unmediated access to one or more of the object’s mutable instance variables. The big idea is that the sender should not be able to assume that the message, `setFoo`, will have any particular effect with respect to the reciever’s state.
- probablybroken 9y ago
  It sounds like you are referring to public properties.
- justincormack 9y ago
  In languages like Lua you can always mediate what look syntactically like setters.
- DougBTX 9y ago
  At least in C# terminology, a "setter" for a public property is mediated access, unmediated access would be a public field that can be set without invoking a setter method. Getters and setters in C# are method calls, like `setFoo` in Java, so can't be assumed to be simple, they can do anything any other method can do.
  - noblethrasher 9y ago
    As it turns out, C# is a language that I know extremely well; I'm aware that setters can have arbitrary code. But, here's the problem: A programming a language is medium for thought, which means that it promotes or prevents the occurrence of certain ideas. So, even though the compiler will accept any legal void-returning code within the inner braces of public Foo Bar { set { //Do stuff } } The fact that the client code is going to look like `Obj.Foo = whatever` will practically foreclose on all but a small subset of possibilities.