[hota_mazi]

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 */ }

[gambler]

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

[rspeele]

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.

[hota_mazi]

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?

[gambler]

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