Post #110,738
7/21/03 5:04:43 PM
|
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
7/21/03 5:08:28 PM
|
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
7/21/03 5:28:58 PM
|
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 call ed object gets to decide, that we're talking about "messages" in the first place. In "FOO", with its call ing-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 messagesposts 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
7/21/03 5:32:53 PM
|
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
7/21/03 5:47:53 PM
|
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
7/21/03 5:49:48 PM
|
Lose the chip...
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #110,749
7/21/03 6:02:31 PM
|
OK, bye, then. (Heard anything from Addison, lately?)
|
Post #110,750
7/21/03 6:03:29 PM
|
Suit yourself.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #110,769
7/21/03 7:41:37 PM
|
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
7/21/03 6:12:31 PM
|
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
7/21/03 6:16:14 PM
|
Mooooooo.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #110,755
7/21/03 6:31:36 PM
|
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
7/21/03 6:35:39 PM
|
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
7/21/03 6:42:26 PM
|
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
7/21/03 6:56:59 PM
|
Sure.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #110,761
7/21/03 7:01:43 PM
8/21/07 5:42:37 AM
|
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
|
Post #110,806
7/21/03 11:42:24 PM
|
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
7/22/03 12:49:34 AM
|
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
7/22/03 12:59:53 AM
|
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
7/22/03 6:01:52 AM
|
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
7/22/03 10:19:58 AM
8/21/07 5:44:33 AM
|
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
|
Post #110,864
7/22/03 10:29:29 AM
7/22/03 10:31:22 AM
|
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
|
Post #111,003
7/22/03 9:19:49 PM
|
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
7/22/03 9:49:03 PM
8/21/07 5:51:46 AM
|
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
|
