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
|
