Talk:Message passing

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Overview has shape example with potential problem violating Liskov Substitution Principle[edit]

Quoting the current version :

Shape with subclasses such as Rectangle and Ellipse (which in turn have subclasses Square and Circle)

This is the typical example of violating Liskov_substitution_principle, (read https://stackoverflow.com/a/28952408/10060021 ). I.e. overriding width/height setters (in Square) to modify data for both width and height at the same time (in base Rectangle) would break Rectangle semantics. The following example would actually expand twice for squares.

  func Expand(Rect r) {
     r.width = r.width + 1;
     r.height = r.height + 1;
  }

There should be at least a warning. --2bam (talk) 16:52, 13 January 2019 (UTC)[reply]

OOP or low level?[edit]

Should this page include the more general concept of sending messages in computer hardware, e.g. network packets; also 'see MPI'. Some systems turn memory accesses into network messages Fmadd (talk) —Preceding undated comment added 11:28, 16 April 2016 (UTC)[reply]

Message passing paragraph[edit]

Object invocation in object-oriented programming (e.g. Simula, Smalltalk, Java, C#, etc.) has often been called "message passing" and implemented using shared memory. In case of concurrent object-oriented languages (e.g. Java, C#, etc.) the implementation can also involve locks (or other facilities of mutual exclusion).

I deleted this paragraph. Simula, Smalltalk, Java, and C# (except for the join calculus-based stuff in Comega) do not use message passing in the concurrency-related sense meant in this article. Talking about implementation just confuses the differences between message passing and lock-based approaches. DavidHopwood 01:06, 9 March 2006 (UTC)[reply]

Sounds like a good edit to me. Interestingly enough, that particular paragraph was added by Carl Hewitt (yes, the Carl Hewitt — sadly no longer a WP contributor). However, I agree that it confuses the issue a bit. OTOH, it is true that object invocation is sometimes referred to as "message-passing". Perhaps it would be worthwhile to have a section (not in the leader) that discusses the differences between OO "message-passing" and message passing in the concurrent sense. That seems to me like a better approach than trying to conflate the two concepts, as the para you've removed did. What do you think? --Allan McInnes (talk) 02:43, 9 March 2006 (UTC)[reply]
I agree that smalltalk does not use message passing in the sense of the article, it just uses the terminology of message passing to describe ordinary OO method invocation. 1Z (talk) 17:56, 9 February 2011 (UTC)[reply]

There is also a 3rd sense for message passing in computer science/maths : "message passing algorithm" are a class of algorithm related to statistics and bayesian inference. For instance : belief propagation, expextation propagation and variational bayes are message passing algorithms. Maybe we need a disambiguation page.

I created the disambiguation page with a link to belief propagation. It may need a page on message passing algorithms at some stage.Henk.muller (talk) 12:25, 23 January 2010 (UTC)[reply]

I disagree with this edit. I agree that the concept of "message passing" is terribly confused and that people use the term often without being clear are they talking about distributed objects or objects that reside in memory together and that the infrastructure and design say for a message oriented middleware system will be radically different than a non distributed Smalltalk system running on on one computer. But that is an issue for the article to explain not to just sweep it under the rug by saying "well that's not REALLY message passing". It's called "message passing" (I've got the Goldberg book right here and I just looked it up) in a LOT of the OO literature and so we need to explain it with that in mind. MadScientistX11 (talk) 18:24, 1 January 2014 (UTC)[reply]

Yo

Jakethorne1983 (talk) 11:35, 1 June 2018 (UTC)[reply]

Low quality[edit]

A pretty low quality page overall, an alphabet soup of sentences by many editors. Some paragraphs are actually correct, however. I do not have time to fix it for another 2 years - so will just have tag it. Will make a good class project as part of the Wikipedia Ambassadors type program. Not a difficult topic, so a few good CS grad students should be able to fix it. History2007 (talk) 08:47, 31 July 2011 (UTC)[reply]

Ugh! Come on guys stop delegating important work like this to students. A lot of people use Wikipedia and IMO the state of some of the computer science articles is weak compared to most technical and scientific articles. And I've seen some terrible articles that were the result of class projects. The people that should write this should be the people that know it and have been actually doing it not people who are learning as they go. MadScientistX11 (talk) 18:27, 1 January 2014 (UTC)[reply]

What? In English, please![edit]

This article reads as if it's part of a Computer Science manual, not part of a generally accessible encyclopedia Alanthehat (talk) 17:52, 3 August 2013 (UTC)[reply]

I rewrote big sections of the article. The topic is fairly technical so there pretty much has to be some jargon but I tried making it more understandable and tried to at least give a high level overview before going into technical details. I removed a few large chunks of text that went into various issues with distributed and asynchronous message handling. I think it would be reasonable to have some new section(s) that go into problems and issues like broadcast, publish/subscribe, locks, transactions, etc. but what was there on those topics before wasn't clear, was poorly written, and wasn't sourced so I felt it was better to delete it and start with something half way readable and expand from there. There were a few technical sections I didn't completely follow (the stuff about calls vs. message passing) but it didn't sound wrong either so I kept anything like that. --MadScientistX11 (talk) 15:01, 2 January 2014 (UTC)[reply]