It's not so much a Language issue...

Post #110,699 by ChrisR 7/21/03 1:30:46 PM Reply	It's not so much a Language issue... ...as it is a way of viewing the interactions of the Objects. The idea is that the objects should "Interact purely by messages, with no assumption of implementation". Now one can say that the smalltalk calls are really just function calls in disguise. Or one can view function calls as just a structured message. But either way, OO should prefer the situation where there is a loose coupling between caller and callee objects. If one carries the messaging perspective to it's logical conclusion, then one should also be prepared to enable messages that can be handled asynchronously - i.e. you send the message but do not wait for acknowledgement that the actions being taken in response to that message are completed. This should entail being able to queue messages, prioritize them, and acknowledge when the message has been handled. Don't know if Smalltalk handles this scenario, but it seems to be the logical path for viewing it as a message/server framework.
Post #110,722 by JimWeirich 7/21/03 3:35:18 PM Reply	Mind Games ChrisR: It's not so much a Language issue as it is a way of viewing the interactions of the Objects So it is a mental view that makes the difference? I assume that one with a MOO mental outlook will produce a (somewhat) different design that someone with a FOO mental outlook. Can you characterize the difference between a MOO design and a FOO design? (same question as before, but considering designs rather than languages) -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,732 by ChrisR 7/21/03 4:30:20 PM Reply	The biggest difference is how one treats the interaction In the case of a function, the calling object is the one that determines whether the called object has the capability to handle the message. Something like: i = obj.yourProc(x, y); where this code checks whether the obj has a method called yourProc which has a signature consistent with the types of the parameters x & y. If it is found that the obj Object does not have such a method, then obj is never bothered with the details, and the calling code spanks itself (either at compile time or run time). In the case of a Message based system, the calling program ALWAYS sends the message to the object (whether it is valid or not). It is the burden of the called object to determine whether it will accept that message or not. In some cases, the method may not exist but you still have the option to dispatch the message to yet another object that will properly handle it (while the original caller remains totally oblivious to this fact).
Post #110,735 by JimWeirich 7/21/03 4:52:33 PM Reply	Now a Language Issue again Paraphrase: FOO gives errors on missing methods, MOO allows the object to decide how to handle missing methods. Is that accurate? Now it sounds like a language difference again instead of (or perhaps in addition to) a mental outlook. (I'm not trying to be difficult. I'm just wrestling with these ideas myself :-) -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,738 by CRConrad 7/21/03 5:04:43 PM Reply	Is it "missing methods" or "invalid messages" it handles? Like Jim, I'm just honestly wondering... AFAICS, now it's a question of perspective again: From the viewpoint of the called object (the one that does (or doesn't do, as the case may be) the handling), it isn't a "missing method" -- it has, as far as it knows, all the methods it needs -- but an "invalid message". It's only from the point of the calling object (or other calling code) that it's a "missing method". And therefore, since the calling-object-centered perspective is what you call 'FOO' here, I think the paraphrase should be, "FOO gives errors on missing methods, MOO allows the object to decide how to handle invalid messages". (Anal? Perhaps... But, hey, I'm a strong-static-typing kind of guy, so what'd you expect? :-) [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #110,740 by admin 7/21/03 5:08:28 PM Reply	Both. The point is that MOO allows the called object to decide whether the message is missing, invalid, or whatever, without having to specify this at compile time. One use is to have a proxy object that can inspect all objects it holds references to internally to decide if any of them can take the message as well. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,744 by CRConrad 7/21/03 5:28:58 PM Reply	Sorry, I don't think you quite understood what I meant. Scott offers: The point is that MOO allows the called object to decide whether the message is missing, invalid, or whatever, without having to specify this at compile time. But we weren't talking about "missing messages" (what would that be, BTW -- "this message I didn't get?" :-) , but "missing methods": My point was, it's only in "MOO", where the called object gets to decide, that we're talking about "messages" in the first place. In "FOO", with its calling-object perspective, we wouldn't be talking about "messages" at all, but methods (missing, or not). One use is to have a proxy object that can inspect all objects it holds references to internally to decide if any of them can take the message as well. Yeah, I know; if Todd hadn't said it a zillion times before, it came up just a few ~~messages~~posts upstream, in this thread. The thing is, once you're seeing it in terms of "...take the message...", you're already firmly in "MOO"-land, so your terminology is -- IMobviouslyNSHO -- already slightly unsuitable for paraphrasing the "FOO" half of the equation. Did all that make anything any clearer? [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #110,746 by admin 7/21/03 5:32:53 PM Reply	Needlessly pedantic, IMO. We've already established that messages might as well be methods (functions), and that MOO handles missing (as in, missing method signature, not just missing method name) method calls. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,747 by CRConrad 7/21/03 5:47:53 PM Reply	OK, so why don't we do it that way, then... Scott replies: We've already established that messages might as well be methods (functions), and that MOO handles missing (as in, missing method signature, not just missing method name) method calls. OK, so let's make the slogan "FOO gives errors on missing methods, MOO allows the object to decide how to handle missing methods". I mean, why not, if they're as equivalent as you say? We wouldn't want to start this off thread, too, on a basis of presupposing that the "message-oriented" terminology is somehow more appropriate, would we...? Not unless we wanted, from the very outset, to arrive at the conclusion "FOO bad! MOO good!", I think... And if that's the case, everybody just please let me know, so I can leave you to carry on the discussion without me. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #110,748 by admin 7/21/03 5:49:48 PM Reply	Lose the chip... Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,749 by CRConrad 7/21/03 6:02:31 PM Reply	OK, bye, then. (Heard anything from Addison, lately?)
Post #110,750 by admin 7/21/03 6:03:29 PM Reply	Suit yourself. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,769 by orion 7/21/03 7:41:37 PM Reply	You can do it (new thread) Created as new thread #110768 titled [link\|/forums/render/content/show?contentid=110768\|You can do it]
Post #110,751 by ChrisR 7/21/03 6:12:31 PM Reply	FOO bad. MOO good. Ok, who's handing out these acronyms anyway. I hope they don't stick. :-) We wouldn't want to start this off thread, too, on a basis of presupposing that the "message-oriented" terminology is somehow more appropriate, would we...? If you did want that capability to dispatch on "Message Not Understood", then dynamic languages definitely have a leg up. It's also possible to do something similar via runtime reflection within a static language, but it's rare for static languages to pursue that path.
Post #110,753 by admin 7/21/03 6:16:14 PM Reply	Mooooooo. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,755 by JimWeirich 7/21/03 6:31:36 PM Reply	Re: FOO bad. MOO good. I claim full responsibility for the acronyms. I just wanted a quick handle to differentiate the two approaches as we defined them. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,756 by JimWeirich 7/21/03 6:35:39 PM Reply	Re: OK, so why don't we do it that way, then... CRC: Not unless we wanted, from the very outset, to arrive at the conclusion "FOO bad! MOO good!", That was not my intention. I would like to nail down the definitions and then move on to pros/cons of each. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,757 by JimWeirich 7/21/03 6:42:26 PM Reply	Method VS Message Scott: We've already established that messages might as well be methods (functions) [...] I think there is a difference between method and message. The method is the code that gets executed in response to receiving a message (Todd, does that jive with Smalltalk usage?). I think you can have the same distinction in function oriented languages. I would use the mapping Method = MemberFunction and Message = Function Invocation. I.e. the message is an event in time and space and a method is code. Does that make sense? -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,759 by admin 7/21/03 6:56:59 PM Reply	Sure. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #110,761 by tuberculosis 7/21/03 7:01:43 PM 8/21/07 5:42:37 AM Reply	Re: Method VS Message I think there is a difference between method and message. The method is the code that gets executed in response to receiving a message (Todd, does that jive with Smalltalk usage?) Yes - you send messages - they are handled by methods. A Smalltalk object is a lot like a web server in that respect - send it a message - if its got a handler mapped to what you asked then you get it, otherwise you get the not found page (#doesNotUnderstand:). So even the lowly integer is a whole server in Smalltalk. From here - its not hard to extend this behavior across a network transparently if you like using proxies on either end of the wire. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:42:37 AM EDT Expand All History
Post #110,806 by deSitter 7/21/03 11:42:24 PM Reply	Re: Method VS Message Is that literally how it is handled internally? I thought Scott literally meant, one can implement messaging behavior with appropriate generation of functions. -drl
Post #110,817 by FuManChu 7/22/03 12:49:34 AM Reply	Didn't you finish that smalltalk history doc Todd showed us? I know you got at least halfway through. ;) Yes, that's how it's handled. Absolutely true that, for example, an integer is a server. Grok that and you've got the gist. I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
Post #110,818 by deSitter 7/22/03 12:59:53 AM Reply	Re: Didn't you finish that smalltalk history doc Todd showed Haven't even really started it - busy days. It's near the top of the list. I'm taking it to Atlanta with me next week... -drl
Post #110,828 by bluke 7/22/03 6:01:52 AM Reply	In theory yes, in practice no The VM will optimize out the actual messages etc. in most cases to improve performance if it is not needed
Post #110,862 by tuberculosis 7/22/03 10:19:58 AM 8/21/07 5:44:33 AM Reply	You must cheat - but you must not get caught Dan Ingalls said that I think - referring to optimization of certain messages (like ifTrue:) by the compiler. The compiler will cheat on certain highly used messages to improve performance - but its generally not visible to the developer that this is going on. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:44:33 AM EDT Expand All History
Post #110,864 by bluke 7/22/03 10:29:29 AM 7/22/03 10:31:22 AM Reply	Yes exactly It is clear that the VM is not going to actually send a message for a := 5 + 3. the performance would be horrible. The VM cheats where appropriate and hopefully the developer doesn't notice a difference (which is why Smalltalk can present everything as an object including so called primitive types like integers, etc., and still offer good performance, the VM knows that 5 is an integer and therefore treats it differently in most cases). The various Smalltalk VM's are very good at this (in fact the whole Hotspot compiler idea came from a Smalltalk implementation). Edited by bluke July 22, 2003, 10:31:22 AM EDT Expand All History
Post #111,003 by Ashton 7/22/03 9:19:49 PM Reply	Hmmm sounds as if Smalltalk's efficacy relies critically upon a very ~~Smart~~ Wise compiler. One wonders how wisdom + Boolean ever once came to be comingled. And if such stellar virtuosity could ever again occur. From the gossip read over years - I gather that this was a Fluke, given the variety of C-class and other successors' non-Wisdom.. so frequently dissected and railed about. OK.. never mind. No credentials here. Ashton
Post #111,008 by tuberculosis 7/22/03 9:49:03 PM 8/21/07 5:51:46 AM Reply	Not so clever There is a table of a few selectors that are handled specially by the compiler. You can change the table and recompile everything in the system. Of course, only the VM/compiler tweakers do this. But the language itself is dead simple. For those interested in the original book detailing how it all works: [link\|http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html\|http://users.ipa.net...book_imp_toc.html] Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:51:46 AM EDT Expand All History
Post #110,745 by ChrisR 7/21/03 5:32:00 PM Reply	At that level, it is a language issue... ...in that you almost required to have dynamic typing - as shutting these things down at compile time prevents the ability to dispatch on "Message Not Understood". But you also have a different mental model for those messages that are "matched". That is, if we have: i = math.factorial(5); or i := math factorial:5. We could interpret either of these to mean either (a) call the factorial function attached to the math object; or (b) send a factorial message to the math object with the parameter 5. Operationally they are probably identical, with syntax really not determining how you interpret the call. However, from a mental standpoint, we would say that in a Message based system, that the math object is not just a repository of functions to be called, but rather a service (or process or task) that can accessed through various messages that can be sent to it - including the factorial message. More fundamentally, each object is basically a Program onto itself but instead of communicating through a Pipe or Command Shell, it communicates via messages.

Welcome to IWETHEY!