6 ms·
Method calls are messages. Same thing. To better understand what Alan Kay is talking about it helps to know a specific fact about Smalltalk, the language he in
by galaxyLogic 8y ago
Method calls are messages. Same thing.
To better understand what Alan Kay is talking about it helps to know a specific fact about Smalltalk, the language he invented. Unlike in C++ or Java or JavaScript Smalltalk objects can not have public data-members. They can only have methods. Methods can read and write the "instance variables" inside the object, no-one else except the object itself can.
This means that objects can only communicate by calling methods. They can not read or write data stored into another object. Thus they are totally ignorant about the "implementation" stored inside other objects. They can "send it messages" meaning call its methods. But because all communications with an object are processed by the methods of that recipient object, the recipient object itself is wholly responsible for the MEANING and effect these method-calls have. "Message-passing" is an apt metaphor for such a thing.
This is "message passing" because it is the recipient object who must ALWAYS INTERPRET ALL messages it receives. Therefore method-calls have the semantics of "messages".
Whereas in Java and C++ and JavaScript the caller of an object can also directly modify other objects without the object being modified being "aware" it is being modified. The "meaning" of such modifications is then determined by whoever makes them. Say I store into your object the property "you.age = 253". But what does that mean what does that signify? Only the other object which stored that value "knows" why it did that, what it "means" what implications it should have for the later progress of the program.
So even though in Java etc. you can implement message-passing simply by calling methods, you can also do other things to the object from their outside than only send them "messages". 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.
- wtroughton 8y ago100% 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(); }
- mav3rick 8y agoThis 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.
- miskin 8y agoThat 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.
- tpush 8y ago„[...] 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.
- mav3rick 8y agoI 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.
- mav3rick 8y agoWhat 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.
- 8y ago
- jayd16 8y agoFunny enough, C# squeezes by this test as any Field declaration can be seamlessly replaced with a Property that injects getter and setter methods.
- deleted 8y ago[deleted]
- pjmlp 8y agoA feature borrowed from Eiffel and Delphi.
- hota_mazi 8y agoI 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.
- isaachier 8y agoHere'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 https://en.wikipedia.org/wiki/Smalltalk
- hota_mazi 8y agoBut 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 8y agoYour 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 https://pozorvlak.livejournal.com/94558.html
- edwinyzh 8y agoI 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.
- jakobegger 8y agoRead-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".
- edwinyzh 8y agoSure, if not implemented as methods that return the value of an internal variable, how can one achieve the "readonly" goal?
- keriati1 8y agoThis is a very good explanation of the correct answer.