IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New 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)
New 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.
New 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)
New 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).
New 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)
New 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]
New 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..."
New 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 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]
New 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..."
New 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]
New Lose the chip...
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New OK, bye, then. (Heard anything from Addison, lately?)
New Suit yourself.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New You can do it (new thread)
Created as new thread #110768 titled [link|/forums/render/content/show?contentid=110768|You can do it]
New 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.
New Mooooooo.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 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)
New 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)
New 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)
New Sure.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:42:37 AM EDT
New 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
New 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!
New 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
New 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
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:44:33 AM EDT
New 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).
Expand Edited by bluke July 22, 2003, 10:31:22 AM EDT
New 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
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:51:46 AM EDT
New 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.

New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:42:14 AM EDT
New 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)
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:42:32 AM EDT
New 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
New nil is an object
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 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
New 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.
New 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.

New 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.
New 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)
New 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.

New 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)
New 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.
New 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.
New 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.

New 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.
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:45:22 AM EDT
New 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)
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:45:29 AM EDT
New 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)
New 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.
New Do you know how they do that?
After all in the end AspectJ compiles into regular Java.
New 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".
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:46:10 AM EDT
New 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)
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:46:27 AM EDT
New 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)
New 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.
New 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)
New 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.
New 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)
New 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. :-)
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:51:08 AM EDT
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:51:13 AM EDT
New 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)
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:51:33 AM EDT
New 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!
New 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]
New 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.
New 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)
New 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.
New 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."
     Message Object Oriented vs Function Object Oriented - (JimWeirich) - (71)
         It's not so much a Language issue... - (ChrisR) - (28)
             Mind Games - (JimWeirich) - (27)
                 The biggest difference is how one treats the interaction - (ChrisR) - (26)
                     Now a Language Issue again - (JimWeirich) - (25)
                         Is it "missing methods" or "invalid messages" it handles? - (CRConrad) - (23)
                             Both. - (admin) - (22)
                                 Sorry, I don't think you quite understood what I meant. - (CRConrad) - (21)
                                     Needlessly pedantic, IMO. - (admin) - (20)
                                         OK, so why don't we do it that way, then... - (CRConrad) - (8)
                                             Lose the chip... -NT - (admin) - (3)
                                                 OK, bye, then. (Heard anything from Addison, lately?) -NT - (CRConrad) - (2)
                                                     Suit yourself. -NT - (admin)
                                                     You can do it (new thread) - (orion)
                                             FOO bad. MOO good. - (ChrisR) - (2)
                                                 Mooooooo. -NT - (admin)
                                                 Re: FOO bad. MOO good. - (JimWeirich)
                                             Re: OK, so why don't we do it that way, then... - (JimWeirich)
                                         Method VS Message - (JimWeirich) - (10)
                                             Sure. -NT - (admin)
                                             Re: Method VS Message - (tuberculosis) - (8)
                                                 Re: Method VS Message - (deSitter) - (7)
                                                     Didn't you finish that smalltalk history doc Todd showed us? - (FuManChu) - (1)
                                                         Re: Didn't you finish that smalltalk history doc Todd showed - (deSitter)
                                                     In theory yes, in practice no - (bluke) - (4)
                                                         You must cheat - but you must not get caught - (tuberculosis) - (3)
                                                             Yes exactly - (bluke) - (2)
                                                                 Hmmm sounds as if - (Ashton) - (1)
                                                                     Not *so* clever - (tuberculosis)
                         At that level, it is a language issue... - (ChrisR)
         DoesNotUnderstand - (tuberculosis) - (6)
             Reified Messages - (JimWeirich) - (1)
                 Sounds about right to me -NT - (tuberculosis)
             Re: DoesNotUnderstand - (deSitter) - (3)
                 nil is an object -NT - (admin) - (2)
                     Re: nil is an object - (deSitter) - (1)
                         Re: nil is an object - (bluke)
         ICLRPD - (static)
         It is a fundamental difference - (bluke) - (30)
             More Questions - (JimWeirich) - (9)
                 Re: More Questions - (bluke) - (3)
                     Re: More Questions - (JimWeirich) - (2)
                         It relates more to the mindset - (bluke)
                         In past discussions with Freep... - (ChrisR)
                 Where does polymorphism fit in? - (static) - (1)
                     Polymorphism via inheritance/interface - (ChrisR)
                 Example - (tuberculosis) - (1)
                     Re: Example - (JimWeirich)
                 Statically Typed Smalltalk - (tuberculosis)
             Statically Typed MOO - (JimWeirich) - (19)
                 The other possible avenue - (ChrisR) - (18)
                     Do you know how they do that? - (bluke) - (17)
                         Compiler generates the necessary calls - (ChrisR)
                         AspectJ is code generation - (tuberculosis) - (15)
                             A comment and a question ... - (JimWeirich) - (12)
                                 Not really - (tuberculosis) - (11)
                                     Pushing the limits of Blanchard's Law - (JimWeirich) - (10)
                                         I don't think the basic argument is so much - (ChrisR) - (8)
                                             Re: I don't think the basic argument is so much - (JimWeirich) - (7)
                                                 Should probably let Todd defend his Laws....but.... :-) - (ChrisR) - (6)
                                                     Still sounds arbitrary ... - (JimWeirich) - (5)
                                                         On par with "Eval" - (ChrisR) - (1)
                                                             Well said -NT - (tuberculosis)
                                                         No its not - (tuberculosis) - (2)
                                                             Ok, I get it. - (JimWeirich) - (1)
                                                                 Yep -NT - (tuberculosis)
                                         Oh yeah - (FuManChu)
                             What is your reasoning for this "law"? - (ben_tilly) - (1)
                                 OT re: coming to this thread late - (drewk)
         Litmus Test - (JimWeirich) - (1)
             Yes and No - (bluke)
         Interesting comp.lang.smalltalk thread on this - (bluke)

Do not ask for whom the bellicose tolls.
218 ms