Hacker News Reader

Comment by noblethrasher | Hacker News Reader

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

[2] https://news.ycombinator.com/item?id=11967631

[3] https://news.ycombinator.com/item?id=11809477

View on HN

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.

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.

It sounds like you are referring to public properties.

In languages like Lua you can always mediate what look syntactically like setters.

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.

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.

But classical setters aren't setters then, because the access is mediated (the are, or are backed by, methods which could do anything.)

Only public fields provide unmediated access.

Please see my reply to a sibling comment: https://news.ycombinator.com/item?id=14255796

I think the problem is that, yeah, they're messages but very low level messages about the state of the object and not at all about a behaviour of the object in response to a message.

I think, however, they're a good way of building objects where a language lacks object or hashmap shorthand (e.g JS and Ruby). In fact, with Obj-C, if my memory serves right, it can look just as expressive.

Setters (particularly fluent), in that case, seem best for building objects in a readable way where a language lacks a way to pass express keyword arguments.

I think in those examples, there are probably smaller objects hiding inside your bigger objects, and you should construct them first.

FYI ruby has named arguments since a few versions back.

I think you're probably right. That's the ideal.

Thanks for letting me know - can't believe I missed that. I don't use Ruby professionally, just as a scripting language to make my life at work easier.

ironically the "java/c#/c++"-ness in this case is precisely a point of difference with objective-c, which has messages, while java has only method invokations. meaning a setter in c++ is (more or less) syntactic sugar for setFoo(objectref, newval), while in objective-c it's more like sendMessage("setFoo",objectref, newval).

the difference might seem minor but the extra layer of inderection means the target object can have centralised logic to handle the outcome of this message if it wamts to, as opposed to repeating and distributing such logic among every method, making it a more independent unit as opposed to something being directly manipulated from the outside.

put another way, the object can decide independently what to do with the message "setFoo" in objective C (or ruby), but in c++ there is no message, no decision, just some code that directly causes something to happen, that can be invoked directly from any other part of the program ar any time, whose results are then relied upon to be visible directly after invokation.

as a thought experiment, imagine if the target object actually exists on a different server, what would the different unsugared implementations need to look like? how would you pause the in progress program to wait for the result of the method invokation? what impact might that delay have on the user?

An object that derives from DynamicObject in C# can have conditionals in its TryInvoke override, so it can change which method calls it responds to. However this sacrifices useful static compile-time checks, so it only gets used in unusual situations where the extra dynamic behaviour outweighs the cost.

> whose results are then relied upon to be visible directly after invokation

I'm not sure I buy that, surely those details are down to the individual methods in question. There's lots of hairy (distributed) COM code out there that doesn't make that promise for example, and it won't hold in a multi-threaded environment for objects that are not explicitly thread-safe in any case.

That's true, and often a well-designed object needs setters, but I think what the parent is getting at is using objects to model dumb data instead of behavior encapsulating state. If an object has getters and setters for all its members, then it isn't really an object. It's a degenerate object that is equivalent to naked data. Not much changes if it has only getters: then it's just immutable naked data.

(Which I think is a good thing, and I hate it when people make blanket assumptions otherwise! And I hate it when languages like Java make it awkward to express dumb immutable data. I think the pieces in a program that are best modeled as "behavior" and "state" is a subset, usually a proper one, often a small one, of the data and functionality that needs to be modeled in a nontrivial program. Often there's a lot of data in a program that is most clearly modeled as dumb data, or at least as transparent data packaged together with some common operations. "Behavior" and "state" is mental overhead that only pays for itself when you have to express a certain amount of complexity. That's why it's so important for a language to let you start in one style, with plain transparent data (and lots of immutability), and switch to encapsulated behavior when you discover that part of the code is complex enough to benefit from it. Otherwise you pay a high mental cost to future-proofing every piece of data with getters and setters and private data when it's possible that only a small portion of your code will ever benefit from it.)

> If an object has getters and setters for all its members, then it isn't really an object.

Minor quibble. Take for example a coordinate class, that you can get/set cartesian, and get/set polar. It's a nice example of an object with no private state, but transparently hides the coordinate system transformations.

In general, i agree with you. The vast majority are just (possibly immutable) structs.

That's actually a really good, concise definition. I might use this in future bikesheddings.

Avoid setters?

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"

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.

Is this to say that `attr_accessor` is too "heavy handed" when just using `attr_reader` could have sufficed?

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.

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.

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.

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?

Why is it changing? have the method name reflect that domain reason, not reflecting the mechanical details of which internal fields need to change.

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

To be clear, I wasn't endorsing the concern, just attempting to clarify it. It doesn't surprise me that it can be over-applied.

For me a setter is something that refers explicitly to data inside the object. It means the world outside the object is now intimately and inappropriately concerned with what's inside the object. The whole point of objects is to make them block boxes and ask them to do higher level things, and hide how they do those things to avoid information overload.

Even if a method does nothing but set an internal field of an object, in my eyes it's not a setter if it performs an actual high level task and doesn't expose the internal structure. IE:

    monster.setDead(true);

Is a setter. While

    monster.Kill();

Is not to me, even if it does the exact same thing inside. The latter doesn't bother me about internal details like some boolean field called "dead".

It's a subtle and almost pedantic distinction, but I hope you see where I'm coming from, and can appreciate the mindshift change from "this is a box full of fields" to "this is an entity".

Thank you :) this is the answer I've been waiting for

Obligatory Casey Muratory rant: https://www.youtube.com/watch?v=_xLgr6Ng4qQ

Reply on news.ycombinator.com