Hacker News Reader

100% agree that in object-oriented programming, only the object itself should care about its internal state. The object should know about its behaviors and what state changes are actually valid.

In Java, many projects overuse getters and setters. Getters and setters break encapsulation. More so public setters since they allow any piece of code anywhere can change the value of an object's internal state at any time.

Consider a class Person. A person has a name, SSN, salary. Let's assume name and SSN cannot be changed. What about salary? We don't have to add a setSalary() method. Instead, we should have something like: public void acceptNewJob(Job newJob) { salary = newJob.getSalary(); }

This is one more layer of abstraction that was unneeded. In your example you went through all the trouble to get the same result. Where as there is no notion of a Job inside the person encapsulation (since you don't set a job field ). It's just the salary the object cares about. So why pass in a Job. It so confusing for the reader.

That example is correct, because in OOP you should not simply change state/value inside other object, because you pretty much end up with anemic domain model where classes are just structs and code that modify it is not part of the class. What parent meant was that you call "accept new job" on person object and then use this object instead of just setting the salary. Maybe it was oversimplified, though.

„[...] in OOP you should not simply change state/value inside other object, because you pretty much end up with anemic domain model where classes are just structs and code that modify it is not part of the class.“

Yep, and that’s pretty much the simplest and most modular design for that problem.

This is one of the cases where OOP(whether using methods or messages) leads to more coupling and less flexibility.

I know what the parent meant. Your explanation now directly contradicts what the code does because even with the Job method you are directly setting salary except now it's a more circuitous way for the sake of abstraction. The person class has no notion of a Job.

What you are referring to our container classes which exist solely to hold members. This is not that case. The setting of salary is one of many behaviors offered by the class.

MVC is not OOP (at least not what OOP was originally) and it's a shame that corruption of the idea was allowed to creep in.

I do like your use of the word "anemic" to describe the method free classes that pass for objects these days.

I especially agree with "This means that objects can only communicate by calling methods". I think we can add another thing - the object can also expose readonly properties, which allows external modules easy accessing the object's state but cannot change it.

Read-only properties would be implemented as methods that return the value of an internal variable. There should be no way to directly access the internal state of an object, even if it is read-only -- because that would prevent you from changing internal details (eg. do you store the property in a float or a double?), breaking the "encapsulation".

Sure, if not implemented as methods that return the value of an internal variable, how can one achieve the "readonly" goal?

I tried hard to understand what you were saying but I still see nothing that messages do and Java methods don't, or the other way around.

Everything you say is confusing to me, but I'll just pick on one:

> An Object-Oriented language according to Alan Kay (according to me) then is one where the only way objects can communicate with other objects is by calling methods i.e. by message passing, never by modifying the objects directly from their outside.

What guarantees that when I send a message to an object, that object won't decide to change itself in response?

In other words, that distinction you are trying so hard to build between message passing and function calling is nonexistent.

Here's an example of the distinct nature of Smalltalk's message passing:

Control structures

Control structures do not have special syntax in Smalltalk. They are instead implemented as messages sent to objects. For example, conditional execution is implemented by sending the message ifTrue: to a Boolean object, passing as an argument the block of code to be executed if and only if the Boolean receiver is true.

The following code demonstrates this:

result := a > b ifTrue:[ 'greater' ] ifFalse:[ 'less or equal' ]

https://en.wikipedia.org/wiki/Smalltalk

But there's nothing specific about message passing to that example, you can do this with regular function calling:

For example in Kotlin:

    class Boolean {
      fun ifTrue(closure: -> ())
      fun ifFalse(... whatever)
    }
    
    a.ifTrue { /* do something */ }

Your class will not work without language-level if/else construct or something equivalent. In Samlltalk if/else is implemented purely through message passing. There is no "real" if/else.

IIRC, Smalltalk has Boolean class and two subclasses of Boolean: True and False. There is a single method with two arguments (:ifTrue:ifFlase). The method is then overloaded. True calls ifTrue argument. Flase calls ifFalse argument. This is happening dynamically, at runtime. Again, the mechanism is generic enough to fully replace all use cases of "traditional" if/else constructs.

Clearly, you haven't thought this through.

Edit: People here would do well to read this: https://pozorvlak.livejournal.com/94558.html

It still doesn't seem to have anything to do with message passing vs method calling. Yes, Java doesn't implement if/else as syntax sugar like that, but it could, and it could use virtual methods to do it and not have to implement a special kind of message-passing method. There is nothing preventing you from writing a SmallTalk on the JVM that uses regular ol' Java methods to do the same thing. So the question remains: what the hell is "message passing" and what differentiates it from a virtual method call?

----

My best guess, especially given Alan Kay's statement "I wanted to get rid of data" is that it is more of a style of coding than a technical distinction. I could be misinterpreting him and it would be nice if he would mention a small and concrete example that illustrates the True Meaning of Messages.

I see it as the style of coding you run into reading AST-processing code in Java, where, because the language lacks discriminated unions and pattern matching, you don't simply look at the `expression` object you're given and see that it is an `AdditionExpression(LiteralInteger(1), VariableName("x"))`. Rather, you politely ask the expression to describe itself to your own `visitor` object, and the structure of the expression reveals itself by calling `visitor.VisitAddition(leftSide, rightSide)`, and the left side calls `visitor.VisitLiteral(1)` and the right side calls `visitor.VisitVariableName("x")`. Data has been reformulated into a series of calls.

That is the same pattern of coding as having booleans be defined by whether they call the ifTrue or ifFalse branch.

Subjectively I despise programming that way and much prefer using a language that lets me define my data structures immutably and precisely without code, then process them with compiler guarantees that I handle all cases. Reading the data types is the fastest way to understand what a piece of code is trying to accomplish. As Fred Brooks said:

> Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

Clearly, you haven't even bothered to read up about Kotlin.

    (a == 1).ifTrue {
      // ...
    }.else {
      // ...
    }

is standard Kotlin with its DSL syntax.

`ifTrue` and `else` are extension methods added to the `Boolean` type.

You know that there have been new developments in PLT since Smalltalk, right?

>`ifTrue` and `else` are extension methods added to the `Boolean` type.

You don't seem to understand what this discussion is about. Extension functions in Kotlin are statically dispatched, so while they are a nice feature, they are completely irrelevant here.

It's not about how your invocation code looks like. The important part is that at some point the code needs to make a decision whether to invoke "if" case or "else" case. Smalltalk achieves this by having two objects/classes (True and False) that handle the same message differently. The implementation of those objects does not have a hidden control flow statement. Your code would.

Which leads to the well known callback hell, no?

I think "callback hell" in this case would be caused by "boolean blindness" and/or lack of abstraction.

General-purpose programming languages, by their very nature, cannot provide us with constructs that are specially suited to our domain; they can only provide us with generally-useful building blocks, like booleans, integers, functions, etc.

We could try to solve our problems using only those languge-provided constructs directly, e.g. using maps-of-lists-of-booleans-of-whatever. In that case, we get "callback hell", pyramids/triangles of doom, etc. because the same code needs to implement our solution and encode information about our domain.

Alternatively, we can use those language-provided constructs to write our own domain-specific constructs; then use those domain-specific constructs to solve our problem.

I've worked with people who avoid this second approach because understanding the solution requires learning those domain-specific constructs, whereas in the first approach we already know how built-in constructs like booleans work.

The nice thing about Smalltalk in this example is that if/then/else, loops, etc. are not built-in; they're library code. This takes them off the pedestal that they occupy in other languages, and makes it easier to think about replacing them with our own tailor-made alternatives.

(Note that this isn't specific to message-passing style OOP; we can also do this with e.g. recursive functions for loops, induction schemes (e.g. Church encoding) for control flow, etc.)

To be pedantic, ifTrue/ifFalse is actually compiled into the method in Smalltalk 80 and not sent as a message, as an optimization.

In practice, Smalltalk methods tend to be very short. Having too many "callbacks" (really it's just asking Block objects for their value; the "lambdas" here are just objects too) is an issue of how you are designing things. A lot of if/else stuff is avoided simply by taking advantage of the kinds of polymorphism Smalltalk allows in the first place.

> What guarantees that when I send a message to an object, that object won't decide to change itself in response?

I don't think that's what the other commenter is saying.

They're saying that internal state is not directly manipulable from external sources. So an object `x` cannot have a method that takes in another object `y` and does `y.foo += 3`. Instead, it must do something like `y.addFoo(3)` to accomplish the goal.

This is superficial in some sense, but then every distinction between various programming languages is superficial if you look at it right. :)

The idea is that the object itself is the only thing which can manipulate its internal state. Therefore, to use these objects, the programmer must have imbued them with the necessary methods. This is restrictive (you have to implement the methods before you can manipulate the state), but this is the core design principle I think the other commenter is trying to tell you about. Objects cannot be manipulated willy-nilly; they must have implemented some method which can be called from the outside. This restriction creates a much more solid barrier of distinction between the responsibilities of the various objects at play.

Right and that is a subtle notion. You may not need that level of encapsulation the same day you are programming it, but as the system grows it gives you benefits in maintainability including observability. That may be why benefits of Object Orientation may not be so obvious to understand on first look, you need to consider the future evolution of the system. We need to see the forest from the trees.

Funny enough, C# squeezes by this test as any Field declaration can be seamlessly replaced with a Property that injects getter and setter methods.

A feature borrowed from Eiffel and Delphi.

This is a very good explanation of the correct answer.