Post #110,693
7/21/03 12:57:05 PM
|
Message Object Oriented vs Function Object Oriented
In the "Great OO Argument Closer" thread, Todd Blanchard shared these thoughts from Alan Kay ... [Kay] thinks people have largely missed the point. Its not so much that there are classes and objects, but that there is a messaging system and every object may be thought of as a server. This is markedly different from the function calling behavior of the so-called "normal" [...] languages. Given that there are Message Object Oriented (MOO) and Function Object Oriented (FOO) languages, I have two questions that I think would be interesting to explore: (1) What is the essential feature or features that differentiate a MOO language from FOO language? (Is it Duck Typing? Dynamic VS static typing? Keyword messages?) (2) Kay obviously prefers a MOO language. What are the inherit advantages of MOO over FOO? How about advantages of FOO over MOO?
-- -- 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,699
7/21/03 1:30:46 PM
|
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
7/21/03 3:35:18 PM
|
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
7/21/03 4:30:20 PM
|
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
7/21/03 4:52:33 PM
|
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
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
|
Post #110,745
7/21/03 5:32:00 PM
|
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.
|
Post #110,752
7/21/03 6:14:09 PM
8/21/07 5:42:14 AM
|
DoesNotUnderstand
It might seem trivial - I assure you it is not.
The Message oriented languages (of which I know Smalltalk and Objective C) make objects act essentially like servers - when messaged they can simply handle the message, ignore the message, forward the message, or signal a fault. The messages themselves are available as a chunk of data to examine, or modify as necessary.
Messages are sent to an object's handler ("method" if you like), or to #doesNotUnderstand: if no handler exists. What you want to do in there is your business but the default is to halt the process and slap a debugger around it.
In function calling languages - the only available option is to handle the message or catastrophically fail.
This mechanism makes possible a number of very powerful techniques that are simply beyond the ken of the average function calling language user.
There's more wrt to the entire system being manipulatable by the programmer but I think the message vs function thing is a key piece.
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,758
7/21/03 6:50:52 PM
|
Reified Messages
So in MOO, the message can be reified as data and manipulated, and the mapping between message and method is looser and can be something other than a simple name/signature mapping.
Is that the essence?
-- -- 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,760
7/21/03 6:57:09 PM
8/21/07 5:42:32 AM
|
Sounds about right to me
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,807
7/21/03 11:45:13 PM
|
Re: DoesNotUnderstand
Wow - that seems to imply that you can send a message to something that doesn't exist yet. That could be useful.
-drl
|
Post #110,843
7/22/03 8:04:50 AM
|
nil is an object
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #110,858
7/22/03 10:07:10 AM
|
Re: nil is an object
Idea more like - send message to object you expect to appear later, and the messages are waiting when it finally shows up. Until then they are in limbo.
-drl
|
Post #110,873
7/22/03 10:49:10 AM
|
Re: nil is an object
If your intermediate Object is smart enough to do that. nil being an Object is very useful, we had a project where we had to print reports, and a lot of the values (from the database) could be nil. We wrote our own print method in all our objects as well as nil. This way we didn't have to litter the code with var isNil ifTrue: [ print null], instead nil knew how to print itself correctly for our reports and we could just send teh same print method to every object.
|
Post #110,792
7/21/03 10:53:46 PM
|
ICLRPD
Kay obviously prefers a MOO language. What are the inherit advantages of MOO over FOO? How about advantages of FOO over MOO? Wade.
Is it enough to love Is it enough to breathe Somebody rip my heart out And leave me here to bleed
| | Is it enough to die Somebody save my life I'd rather be Anything but Ordinary Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #110,827
7/22/03 5:56:45 AM
|
It is a fundamental difference
In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking. A major difference is flexibility.
In a MOO system I can always send a message to another Object, and if he doesn't know what to do with it he can forward it to someone else, or state that he doesn't understand it, look at the message and fiure out what to do, etc. It is up to the receiving object to decide what to do (not the compiler). Not only that, but the messages themselves can be stored, modified, etc. A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases. In fact Proxy objects are typically implemented like that. This is why distributed systems are so much simpler and cleaner in Smalltalk.
In a FOO system none of this possible. If the system is statically typed like Java, the compiler won' let me do this, and if the system is dynamically typed the call will fail. There are no messages that can be looked at, stored etc. This makes a FOO system much less flexible. For example to write a proxy in Java was a non-trivial task, they had to introduce special API's just to do this.
|
Post #110,832
7/22/03 6:28:12 AM
|
More Questions
bluke: In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking.
Can you give some concrete examples of the different ways of thinking? You mention distributed systems in your message. Any others?
bluke: A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases.
Is this a hard requirement? Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help?
-- -- 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,838
7/22/03 7:23:18 AM
|
Re: More Questions
bluke: In a MOO system, objects pass messages back and forth, in a FOO system objects execute functions on other objects. It leads to different paradigms and different ways of thinking.
Can you give some concrete examples of the different ways of thinking? You mention distributed systems in your message. Any others?
The ability to capture messages can be very useful. For example, undo/redo can be implemented using this (you trap every message sent and then you can either undo them or redo them quite easily as you have the original message). Logging security can be done with this facility as well.
The other place its shows is in areas like constructing new objects, conditional logic, etc.. In Java, you have a special keyword new and a constructor is called. In Smalltalk, all you do is send a message to the class object to create a new instance, perfectly logical. In Java if then else is a language construct. In Smalltalk it is a message send. When you think in terms of messages, it makes sense to send a message for everything including object creation and conditionals.
bluke: A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases.
Is this a hard requirement? Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help?
I am not an expert on type inference or Haskell, but I don't see how it would help. For example how would it handle a proxy object which can take any message and just forwards it somewehere? A static type system would just impose constraints. Of course, using DoesNotUnderstand is not the normal way of doing things in Smalltalk, so type inference might be useful in those other cases.
|
Post #110,840
7/22/03 7:54:36 AM
|
Re: More Questions
bluke: The ability to capture messages can be very useful. [undo/redo and logging mentioned]
I agree with the above, however ...
bluke: The other place its shows is in areas like constructing new objects, conditional logic, etc.. [...]
These examples are not so clear to me. Exactly how does the MOO-ness of a language contribute to object construction and conditional logic. For example, it is possible (although tedious) to do condition logic in Java (I've done it). However, most of the tedium would be aleviated by a simple anonymous closure syntax and relaxed type rules. Given those, I'm not sure how a message based system (ie. the ability to reify messages) would contribute.
-- -- 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,842
7/22/03 8:03:03 AM
|
It relates more to the mindset
In a FOO like language you are calling functions, therefore to call a function like new is not out of synch with the language, in a MOO language where everything is messages then everything is messages including object construction.
Again, this is more related to mindset and feel then anythng concrete.
|
Post #110,857
7/22/03 9:52:34 AM
|
In past discussions with Freep...
...one of the things that he talked about was the ability to use the mechanism to do some creative dispatching - specifically a mechanism that emulated multiple-dispatch or a Visitor type scenario.
|
Post #110,848
7/22/03 8:42:30 AM
|
Where does polymorphism fit in?
I had a brief discussion with a colleague today about what polymorphism was. It seems to me that a MOO-type language would handle polymorphism better because the determination about what type of object it is occurs at invocation time, whereas in a FOO-type language, this could not be so because the compiler needs to know the object type.
Except it doesn't. C++ is a FOO-type language, but it supports polymorphism.
Wade.
Is it enough to love Is it enough to breathe Somebody rip my heart out And leave me here to bleed
| | Is it enough to die Somebody save my life I'd rather be Anything but Ordinary Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #110,854
7/22/03 9:37:43 AM
|
Polymorphism via inheritance/interface
Static languages achieve their polymorphism either through a common base class or an interface implemented by the class. In dynamic languages, you just call the method and it either responds or it doesn't. This means that the Types in dynamic languages are much more fluid.
|
Post #110,881
7/22/03 11:19:07 AM
8/21/07 5:45:22 AM
|
Example
GLORP (Generic Lightweight Object Relational Persistence) allows you to specify queries as blocks of code.
db readManyOf: User where: [:user | user username = 'Blanchard' && user password = 'passW0rd' ].
given a table: CREATE TABLE USER (USER_NAME varchar(60), PASSWORD varchar(60))
how can this work?
The second argument to readManyOf:where: is a block of code. The block is evaluated with a MessageLogger standing in for user. ie
readManyOf: aClass where: aBlock | aMessageLogger | aMessageLogger := MessageLogger forClass: aClass aBlock value: aMessageLogger.
The MessageLogger's doesNotUnderstand is examining the messages and producing an equivalent SQL translation based on some attribute to column mapping data it has. Since even the operators are actually messages, this is relatively straightforward to do. In Smalltalk that is.
This is just plain impossible in Java/C++/Object Pascal/etc.
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,885
7/22/03 11:45:27 AM
|
Re: Example
GLORP [...]
Fascinating. I've thought about this problem, but assumed that the code block would have to be parsed. Executing the block and tracing the messages is a great example of "out of the box" thinking.
-- -- 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,883
7/22/03 11:28:48 AM
8/21/07 5:45:29 AM
|
Statically Typed Smalltalk
Can you imagine a static type system that would allow MOO-like constructions? Would type inference (like in Haskell) help? The project was called Strongtalk. [link|http://www.cs.ucsb.edu/projects/strongtalk/pages/index.html|http://www.cs.ucsb.e.../pages/index.html] "The Strongtalk system was developed in secret in the mid-90's by a small startup company. Before the Strongtalk system could be released, the company was acquired by Sun Microsystems, Inc. to work on the Java\ufffd virtual machine[1]. Development of Strongtalk was halted at that point, so very few people have ever had a chance to see the Strongtalk system in action." There is some work going on in VM optimization to duplicate this and provide optional static typing. Optional static typing makes optimization much easier and consequently the thing can run faster by taking advantage of more highly optimized routines. [1] - Fuckers.
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,870
7/22/03 10:41:22 AM
|
Statically Typed MOO
bluke: [...]A MOO system cannot be statically typed because an Object in a MOO system can handle any message that it doesn't understand (e.g. not for it's type) in any way that it pleases. [...]
I've been thinking on this. Suppose our statically typed language had a rule that if a class implements "does_not_understand(m: METHOD; args: TUPLE)", then any method calls that would normally cause a compile error would instead be compiled to call "does_not_understand" instead, manifesting the data for the message. There would also have to be a "send(m: METHOD; args: TUPLE)" method defined in Object that would do the obvious.
Modern Eiffels already support the TUPLE for reflection and agents (i.e. lightweight anonymous closures), so I don't expect that the above would present any technical obstacles.
In other words, a statically typed MOO language is not inconceivable.
-- -- 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,872
7/22/03 10:47:24 AM
|
The other possible avenue
is something like what they are doing with AspectJ wherein you set up Aspects that will intercept (i.e. place themself before or after function calls). Apsects can be defined with wildcards, such that any method that matches the expression can be captured. Hence, you could set up an aspect to capture all function calls of a certain pattern - even if the pattern did not currently have a function that met that pattern.
|
Post #110,876
7/22/03 10:54:10 AM
|
Do you know how they do that?
After all in the end AspectJ compiles into regular Java.
|
Post #110,878
7/22/03 11:02:54 AM
|
Compiler generates the necessary calls
Currently doesn't handle calls to non-existent functions, but it does allow you to intercept function calls (before and after). Theoretically, you could extend this to look for calls to non-existent functions and have the AspectJ compiler trap them, but it does assume that you can determine that it doesn't exist at compile time.
Not saying that this is a clean solution, but if you were trying to add said capability onto a static language, it might help to look at how AspectJ goes about it's business of intercepting "messages".
|
Post #110,904
7/22/03 1:00:28 PM
8/21/07 5:46:10 AM
|
AspectJ is code generation
and thus violates Blanchard's law (Systems that require code generation lack sufficient power to tackle the problem at hand).
I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either.
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,915
7/22/03 2:19:07 PM
|
A comment and a question ...
Todd: I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either.AOP is still maturing and I don't think most people understand how to use it effectively. Besides, I have a theory that a highly dynamic language with good reflection will do the many AOP-ish things without the need for full AOP. In other words, there is less need in Smalltalk for AOP. Now for the question regarding Blanchard's law ... In Ruby, we can write ... class Point\n attr_accessor :x, :y\n ...\n end which will generate four methods (getters and setters for both x and y). It is essentially the same as writing ... class Point\n def x\n @x\n end\n def y\n @y\n end\n def x=(value)\n @x = value\n end\n def y=(value)\n @y = value\n end\n ...\n end Does this count as code generation?
-- -- 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,919
7/22/03 2:37:04 PM
8/21/07 5:46:27 AM
|
Not really
the code is trivial and amounts to naked attributes.
C++ templates OTOH do count - as does Java RMI/C++ CORBA (generation of proxies as a standard development technique - primarily required to satisfy the compiler in a FOO environment).
My GLORP interface library will create missing attributes and accessors based on schema requirements - but this is hardly "code generation" - rather its dynamic object reshaping.
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,932
7/22/03 3:57:21 PM
|
Pushing the limits of Blanchard's Law
As you might guess, I like to push the limits a bit. Hope you don't mind. (I'll even tie this question back to message based OO). I hadn't heard of Blanchard's law, so a google search brought up this ... Yeah but it [dynamic Java proxies] breaks Blanchard's law of code generation. Dynamic proxies basically construct classes and load them on the fly by generating code to forward interface calls to implementations. So the system relies on code generation (binary code generation in this case) to do its thing. -- tblanchard@mac.com ([link|http://lists.xml.org/archives/xml-dev/200210/msg01206.html|http://lists.xml.org...210/msg01206.html]) I'm assuming this is the Blanchard for whom the law is named. Keeping the above quote in mind, consider the following code ... class SlowProxy\n def initialize(target)\n @target = target\n end\n def method_missing(sym, *args, &block)\n @target.send(sym, *args, &block)\n end\nend It uses method_missing (Ruby's equivalent of doesNotUnderstand) to forward messages to the proxy target. It works great, but is a bit slower than a hand written proxy because :method_missing overhead. We can rewrite it slightly to do the following ... class FastProxy\n def initialize(target)\n @target = target\n end\n\n def method_missing(sym, *args, &block)\n define_forwarding_method(sym)\n self.send(sym, *args, &block)\n end\n\n def define_forwarding_method(sym)\n self.instance_eval %{\n def #{sym.to_s}(*args, &block)\n @target.#{sym.to_s}(*args, &block)\n end\n }\n end\nend The first time a method is called on the proxy, it dynamically defines a specific forwarding method of that name. Further calls of that same method will no longer go through the :method_missing mechanism. The code generation piece is quite similar to that in the attribute example earlier. But since this dynamic proxy generates method definitions on the fly (just as the Java version does), does that mean this code runs afoul of Blanchard's law as well? It would seem it does. Seems inconsistent to me.
-- -- 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,933
7/22/03 4:09:32 PM
|
I don't think the basic argument is so much
against code generation - especially runtime code generation - so much as it is about using code generation at compile time to trick the compiler into bypassing the static type checking. Smalltalk can generate code on the fly as well, and methods can be attached dynamically in much the same way that you showed in Ruby.
One question, though. Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing. Just thinking that same methods are temporary methods (closures or delegates), that have a limited lifetime or change according to the context.
|
Post #110,940
7/22/03 4:35:10 PM
|
Re: I don't think the basic argument is so much
ChrisR: [...] as it is about using code generation at compile time to trick the compiler into bypassing the static type checking
But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages.
Oh well. Moving on.
ChrisR: Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing.
Yes. remove_method(symbol) will remove it from the current class, but leaves any definitions in the super classes intact. undef_method(symbol) will remove it from the entire class hierarchy.
-- -- 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,946
7/22/03 5:03:54 PM
|
Should probably let Todd defend his Laws....but.... :-)
But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages. I'm guessing, but I don't think the question is whether code generation (or macros) is inherently and evil in and of itself - it can be a useful technique in limited circumstances. The problem is when you begin to rely on such techniques as a workaround to the Type system - and yes it's biased against Static Typing because ST tends to want to prevent you from doing things. In the case you cite, you could have handled the missing_method with any number of techniques - including generating a function on the fly.
|
Post #110,948
7/22/03 5:14:31 PM
|
Still sounds arbitrary ...
ChrisR: and yes it's biased against Static Typing because ST tends to want to prevent you from doing things.
So it is OK to do if you don't need it. But if it you do need it, then it is not ok.
-- -- 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,951
7/22/03 5:20:45 PM
|
On par with "Eval"
Which was how we got into this thread in the first place. Eval and Dynamic Code generation are powerful features. The problem is that when you start requiring these facilitaties to get around the barrier put up by the compile (aka Static Typing), then they are no longer luxories. It is indicative of the fact that you are fighting the language in order to achieve your ends.
Of course, it's the Blanchard Law, so I'll let him be more specific about the intents. Just trying to further the conversation. :-)
|
Post #110,963
7/22/03 6:10:00 PM
8/21/07 5:51:08 AM
|
Well said
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,964
7/22/03 6:11:20 PM
8/21/07 5:51:13 AM
|
No its not
Your example does not rely on code generation to work - it uses it as an optimization. You could (and do) make it work without the code generation.
There's the razor.
If the only way to accomplish a task is code generation - then the tool is not appropriate for the task.
As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P
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,982
7/22/03 7:48:18 PM
|
Ok, I get it.
I was trying to use the law in determining when code generation is a good idea. That's not what the law is for. It is a measure of the power and/or flexibility of your implementation language.
I'm ok with that.
Todd: As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P
Heh, clever line. :-)
-- -- 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 As to whether this is designed by me to punish static languages. Turnabout is fair play. :-PEmde Boas)
|
Post #110,987
7/22/03 8:17:05 PM
8/21/07 5:51:33 AM
|
Yep
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,937
7/22/03 4:28:15 PM
|
Oh yeah
I had dinner with THAT Blanchard once. Much clearer thinker than our Todd.
:D
I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
|
Post #118,380
9/21/03 5:20:53 PM
|
What is your reasoning for this "law"?
Sorry that I am coming to this thread late...
When I hear something like that I automatically think that the underlying reasoning is sort of like that which lies behind using structured flow control mechanisms rather than goto. Namely that the structured mechanisms make it easier to express your thoughts in ways which you or someone else can figure out later.
For instance this is why I prefer to see closures where eval could do the job. And I have heard similar reasoning from Paul Graham on why it is better to use macros rather than eval as well.
Was that your reasoning, or did you have a different motivation?
Cheers, Ben
"good ideas and bad code build communities, the other three combinations do not" - [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #118,427
9/22/03 10:32:55 AM
|
OT re: coming to this thread late
Man, this is going to be like when Scott put in the [link|http://z.iwethey.org/forums/actions/content/random|Random Post] link.
===
Implicitly condoning stupidity since 2001.
|
Post #110,837
7/22/03 7:03:41 AM
|
Litmus Test
If the difference between MOO and FOO languages is the reification of messages, then I propose a simple litmus test: Write a decorator like class that will: (1) Pass any message through to its decorated object. (2) Record the sequence of messages that passed through it. (3) Playback the messages to a different object.[1] The theory is that this should be almost trivial in MOO languages and difficult in FOO languages. Example Usage: \n s = "Hello, World"\n pb = PlayBack.new(s)\n pb.upcase!\n pb.reverse!\n puts str # => 'DLROW ,OLLEH'\n\n t = "yikes"\n pb.playback_on(t)\n puts t # => 'SEKIY'\n Note [1]: For simplicity, we are assuming the "playback_on" message isn't recorded or passed on. Although in theory this is a hole in the spec, it doesn't really effect the litmus test.
-- -- 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,839
7/22/03 7:34:46 AM
|
Yes and No
To write a specific decorator class for a specific object is relatively straightforward in Java (if the object implements an interface), for example you can use a java.lang.reflect.Proxy. What Smalltalk gives you is the ability to create a generic decorator which can front any arbitrary object (changeable at runtime). That will be very difficult in a FOO like language.
|
Post #110,844
7/22/03 8:16:51 AM
|
Interesting comp.lang.smalltalk thread on this
The first post is a great summary [link|http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=363ec108.76648424%40enews.newsguy.com&rnum=3&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3D%252Bsmalltalk%2B%252Bjava%2B%252Bmessage%2B%252Bparadigm%26btnG%3DGoogle%2BSearch|Musings on messages]
"Hi all,
Having only recently returned from OOPSLA '98 (my first of many, I hope), I thought I'd share a few thoughts that I've been tossing around in my mind. I'm still fairly new to Smalltalk (within the last year), so we'll see what kind of response/corrections I get. :)
I've been reading parts of the "purple book", and the first or second chapter describes the fundamental concepts at work in the Smalltalk environment. Among these, the most striking was the differentiation between a "message" and a "method". I realized that I'd never truly separated these concepts in my mind.
The sticky point is the statement that "a message requests that a method be performed" (not cited from anywhere, that's a quote from me). To a lot of people, this seems like a remote function call. But that's not the Smalltalk way. In Smalltalk, the message is not bound to a particular function -- we can turn around and fire the same message off to a completely different object, which may have a completely different method for returning an object to me. We don't care how the message is handled, we just want the message handled appropriately.
This is an absolutely fundamental aspect of the OO paradigm. Without it, objects are just functions bound to their data. Everything is just a function, they just exist in these "class" things, which is like their home or commune where they share data.
I picked up a Java book (can't remember the title) a couple of days ago -- published by Sun -- which aimed to explain Java to anyone with any sort of programming background. Guess what it described: "method calls". When requesting that an object do something, we "call a method" that exists in that object. Sounds like functional programming (albeit with "function houses") to me.
This seems to have consequences for typing, too. If we're calling functions, then we, the caller, need to know what type of arguments the function requires. It just seems to get uglier from here. We'd probably have to overload operators now, because "+" and "-" aren't messages -- they're bound to a procedure, which is in turn bound to a specific object.
Messaging makes this elegant and simple."
|