"Smalltalk style messaging" vs "Method call"
Mircea
around this notion about messaging vs method call. Why one and not the
other...?!
I have dug deep enough to figure out what was the "need" that lead to
this solution, or rather what this kind of implementation offered in
comparison to others. From what i've seen the beginning was mainly
putting "this" and "this" in and tasting the "soup". Eventually people
kind of figured out what was needed based on what the problems seemed
to be. But there is this feeling that i am missing "ground zero" when
it comes to where this thing sprouted from.
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
""1.Everything is an object
2.Objects communicate by sending and receiving messages (in terms of
objects)
3.Objects have their own memory (in terms of objects)
4.Every object is an instance of a class (which must be an object)
5.The class holds the shared behavior for its instances (in the form
of objects in a pogram list)
6.To eval a program list, control is passed to the first object and
the remainder is treated as its message
Perhaps the most important principle--again derived from operating
system architectures--is that when you give someone a structure,
rarely do you want them to have unlimited privileges with it. Just
doing type-matching isn't even close to what's needed. Nor is it
terribly useful to have some objects protected and others not. Make
them all first class citizens and protect all. ""
This whole thing sounds like a physics course where you reach the
*limit* and you have to say... this is how it works, and we have no
idea why, nature just does it!
I'm making an appeal to more experienced minds. Does anyone care
provide some insight? Is (mere) observation in this "space" key?
Raoul Duke
> I've been ploughing through a lot of text lately. I can't wrap my head
> around this notion about messaging vs method call. Why one and not the
> other...?!
i do not know the real reason or history. so i am curious to learn, too.
my impression is that method calls were sort of a typical
misunderstanding / overzealous premature optimization implementation
of messaging. (method calls tend to be more tightly bound than the
dynamic nature of messaging.)
sincerely.
Trygve Reenskaug
The message is the intent, the method is the implementation.
In between, you find the method lookup table that selects the correct method for an incoming message.
- (Different classes bind different methods to the same message).
More about this in an article I'll be posting shortly: "The DCI execution model".
Cheers
--Trygve
Trygve Reenskaug mailto: try...@ifi.uio.no
Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
Sebastian Kübeck
the Lively Kernel:
http://www.infoq.com/interviews/ingalls-smalltalk
As far as I remember it, performance was really the main reason
why they introduced methods. At least in Smalltalk.
Sebastian K�beck
Mircea Samoila
Thanks!
It confirmed some of my expectations. Objective C is just Smalltalk that
couldn't let go of the C legacy. I can see the (old) reasoning behind this
decision. Sure now we have to deal with its syntax but hey... they took what
was available and made of it, something more.
Smalltalk seems to be VERY versatile, it's dynamic+objective nature means I
can replace an object and write it in another language altogether, just plug
it in and go.
What I can't get, is why would the "newer" languages like C# opt out of
messaging. Why would anyone want, like Raoul said, WANT a more "tightly
bound" less dynamic, ecosystem.
Less dynamic means you can navigate adjacent objects easier
(intellisense?!), and via this, people learn/use the your library faster.
But being tightly bound at the same time would make everything like
"glue"... hard to escape. Once you en"code" your project with the "help" of
a certain library, you're stuck. Misunderstood(bad) OO can "help" this even
more, there is no clear boundary, you'd have to replace whole parts of your
implementation at a time, with no "hot-wire" capability.
It seems I'm describing the perfect business model for someone dealing in
software "coin". This needs more peering into...
-----Original Message-----
From: object-co...@googlegroups.com
[mailto:object-co...@googlegroups.com] On Behalf Of Sebastian Kübeck
Sent: 20 octombrie 2010 10:13
To: object-co...@googlegroups.com
Subject: Re: "Smalltalk style messaging" vs "Method call"
Maybe it helps if you watch Dan Ingalls on the History of Smalltalk and the
Lively Kernel:
http://www.infoq.com/interviews/ingalls-smalltalk
As far as I remember it, performance was really the main reason why they
introduced methods. At least in Smalltalk.
Sebastian Kübeck
--
You received this message because you are subscribed to the Google Groups
"object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to
object-composit...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/object-composition?hl=en.
Raoul Duke
it, sorry for the repetition.
sincerely.
On Wed, Oct 20, 2010 at 1:37 PM, Raoul Duke <rao...@gmail.com> wrote:
> i can think of several reasons off the top of my head :-)
Raoul Duke
<samoila...@gmail.com> wrote:
> What I can't get, is why would the "newer" languages like C# opt out of
> messaging. Why would anyone want, like Raoul said, WANT a more "tightly
> bound" less dynamic, ecosystem.
i can think of several reasons off the top of my head :-)
* compile-time understanding of the system?
* ability to give code to other people and not have to find out that
they've changed their running image over time so like, oh i dunno,
Boolean (mostly kidding, but you never know) is not compatible?
* performance?
* generally wanting to interact with other languages/systems?
sincerely.
Ant Kutschera
Is messaging like:
doSomething(a, b, c)
and a method call like:
anObject.doSomething(f, g)
?
Because something as started to ask myself earlier in the week while
reading schärli's thesis on traits, was why methods need to be bound
to objects... sure sometimes it makes sense. other times it doesnt.
right from the start of his thesis, he never ever questions whether
method calls could be seperate from the objects, he just assumes they
need to be attached to objects. that assumption seems to be something
which DCI makes too.
Cheers,
Ant
ps - i have almost NO academic training in IT :-)
Raoul Duke
> ps - i have almost NO academic training in IT :-)
ah, that must be why you are one of the apparently more insightful
folks. (seriously.)
James O. Coplien
A method is an operation on an object. It has a name, called a method selector, and it can have arguments (formal parameters). In Smalltalk, methods are also objects.
A message is a combination of an object identifier, method selector, and actual parameters, bundled together for dispatching to an object. The environment causes the message to be "routed" to the right place based on the object identifier (which in turn can be used to find a method lookup table) and the method selector.
The nomenclature in C++ is different. C++ has neither methods nor method selectors, but has member functions.
I don't know the nomenclature, in detail, for other languages.
Trygve Reenskaug
s
queareArea(x) or circleArea(x) where x
is the size of the square or the radius of the circle.In object-oriented programming you can say
x.areaClass
Square will have a method called area
(=squareArea), class Circle will have its own and
different method called area (=circleArea). The two
methods are different, but they can be called the same since they are
defined in different classes.The message is
area, it is asking the receiver 'to do the
right thing'.So we have one message, two methods. Java confuses the two concepts. This is not a problem for the compiler, only a confusion in the minds of the Java designers and some of its users.
Just for the record: A Smalltalk method is no more an object than a boy called Peter is an object. But both can be represented by an object, but that's not the same thing at all.
--Trygve
Mircea Samoila
Thank you for the explanation.
It’s really interesting how the concepts behind Smalltalk seem to have a certain logic to them, or should I say that the assumptions seem to be correct.
I’ve been reading further back “in time”, to Dijkstra and SUPRISINGLY to Christopher Alexander who incidentally is an architect.
His Notes on the Synthesis of Form, and A Pattern Language read into Smalltalk very well. He seems to have influenced things a lot.
Guess I’ve gone full circle.
Mircea.
From: object-co...@googlegroups.com [mailto:object-co...@googlegroups.com] On Behalf Of Trygve Reenskaug
Sent: 21 octombrie 2010 12:24
To: object-co...@googlegroups.com
Subject: Re: "Smalltalk style messaging" vs "Method call"
In procedure-oriented programming you must say
--