The future of objective-C
Jamie Curmi
I've only just discovered Objective-C -playing with MacOSX basically. So
I've been doing a bit of research and it seems quite nifty (though the
syntax is kind of strange).
Now, I'm not trolling, I'm seriously wondering what the future holds for
Objective-C. Clearly NeXT has done some amazing things with it, and I'm
sure others have. Do you guys see a future for it beyond the niche that it
currently has? Is there a possibility Apple could do something with it
making it a Java alternative on all platforms (make the syntax more like
C++/java, but make it compiled not interpreted, perhaps)?
I've read some people are worried because WebObjects will soon be (if not
already?) working with Java, and Apple may be concentrating on the Java side
of web objects as that is the current flavour of the month.
I'd love to hear everyone's thoughts on this. What does the future hold?
Jamie
mike burrell
> Now, I'm not trolling, I'm seriously wondering what the future holds for
> Objective-C. Clearly NeXT has done some amazing things with it, and I'm
> sure others have. Do you guys see a future for it beyond the niche that it
> currently has? Is there a possibility Apple could do something with it
> making it a Java alternative on all platforms (make the syntax more like
> C++/java, but make it compiled not interpreted, perhaps)?
i doubt that Apple will kill off Objective C development entirely. they
have a lot of legacy code written for it. plus, it's a good language :)
> I've read some people are worried because WebObjects will soon be (if not
> already?) working with Java, and Apple may be concentrating on the Java side
> of web objects as that is the current flavour of the month.
if i were Apple, i'd be looking at getting Java and Objective C talking
together. Java has its RMI; Foundation has its NSDistributedObject; then
there are RPC, CORBA, etc. they're all fairly similar, though.
> I'd love to hear everyone's thoughts on this. What does the future hold?
Objective C has a life outside of Apple/NeXT. if Apple were to abandon it,
the developer pool might get cut in half, which would suck, but wouldn't do
too much to halt the progression of Objective C in general.
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@home.com
X AGAINST HTML MAIL,
/ \ AND NEWS TOO, dammit finger mik...@mikpos.dyndns.org for GPG key
John C. Randolph
Jamie Curmi wrote:
>
> Hi All,
>
> I've only just discovered Objective-C -playing with MacOSX basically. So
> I've been doing a bit of research and it seems quite nifty (though the
> syntax is kind of strange).
>
> Now, I'm not trolling, I'm seriously wondering what the future holds for
> Objective-C. Clearly NeXT has done some amazing things with it, and I'm
> sure others have. Do you guys see a future for it beyond the niche that it
> currently has?
Well, with Mac OS X server alone the number of Obj-C developers took a major
leap. If you take a look at the lists that Omni maintains, you'll see more
new Obj-C developers than anytime in the last ten years.
>Is there a possibility Apple could do something with it
> making it a Java alternative on all platforms (make the syntax more like
> C++/java, but make it compiled not interpreted, perhaps)?
Not likely. Apple floated the idea of a new syntax for Obj-C that
looked like
Java, and we made sure that the so-called "modern syntax" got put up against
the wall and shot through the head.
As for the cross-platform capabilities that Apple's pissing away, I suspect
that some kind of backroom deal with Sun and/or MicroSquish will prevent Apple
from ever shipping Cocoa for windoze (as they promised at THREE consecutive
Worldwide Developer Conferences.)
> I've read some people are worried because WebObjects will soon be (if not
> already?) working with Java, and Apple may be concentrating on the Java side
> of web objects as that is the current flavour of the month.
Web Objects is a lost cause. The much more important issue is the preservation
of an Objective-C Enterprise Objects Framework.
> I'd love to hear everyone's thoughts on this. What does the future hold?
I see Obj-C becoming the language of choice for Macintosh development,
and
possibly for GUI apps on Linux when GNUStep nears completion.
-jcr
Frederic Stark
> Hi All,
>
> I've only just discovered Objective-C -playing with MacOSX basically. So
> I've been doing a bit of research and it seems quite nifty (though the
> syntax is kind of strange).
Huh ? You means it lacks goodies like:
A::B C::D<T0<T1> >() { return 42; }
or
return new MyClass { int f() { return 42; } };
Don't say the syntax is strange. Says that it is a new syntax for you.
> Now, I'm not trolling, I'm seriously wondering what the future holds for
> Objective-C.
Furture of objc is much better shaped now than 2 years ago, when apple wanted to kill it.
> Clearly NeXT has done some amazing things with it, and I'm
> sure others have. Do you guys see a future for it beyond the niche that it
> currently has? Is there a possibility Apple could do something with it
> making it a Java alternative on all platforms (make the syntax more like
> C++/java, but make it compiled not interpreted, perhaps)?
It doesn't make sense. Why do you want to change objc syntax ? And, IIRC, compiled compiled java exists too.
Btw, neither objc nor java are interpreted, so I have trouble understanding you.
Anyway, you should ask directly apple about what they plan to do. (I can give you a slight info anyway, they probably don't know. And even if they know, they'll probably do something else anyway)
> I've read some people are worried because WebObjects will soon be (if not
> already?) working with Java,
WebObjects always worked with java. In fact you can mix/match objc and java with apple run-time. Now, WO5 will be a java-only product, but the relationship between WebObjects and objc is really thin.
[crunch];
> I'd love to hear everyone's thoughts on this. What does the future hold?
We'll see. Thanks god, there is place for more than one language.
Cheers,
--fred
Doc O'Leary
<jcu...@bigpond.net.au> wrote:
> I've only just discovered Objective-C -playing with MacOSX basically. So
> I've been doing a bit of research and it seems quite nifty (though the
> syntax is kind of strange).
Embrace the oddity. You'll come to question why other languages use
such an anemic syntax.
> Now, I'm not trolling, I'm seriously wondering what the future holds for
> Objective-C.
I'm not sure what you mean. I'll use it to implement a solution when
it makes sense to do so, and I'll use other languages when they seem
appropriate. Unlike Sun, I can't control market forces, so it doesn't
worry me in the least that ObjC is being jammed down everyone's throat.
I have a technical need, not a marketing need.
> Is there a possibility Apple could do something with it
> making it a Java alternative on all platforms (make the syntax more like
> C++/java, but make it compiled not interpreted, perhaps)?
As has been pointed out by others, a Java-style syntax for ObjC has
been proposed, judged lacking, and discarded. If you want Java, use
Java. If the Java object system does not meet your needs, prepare to
learn a little new syntax to access the features of a different object
system.
> I've read some people are worried because WebObjects will soon be (if not
> already?) working with Java, and Apple may be concentrating on the Java side
> of web objects as that is the current flavour of the month.
It's not just "working with Java" that concerns me; WebObjects has done
that for some time. It's the "requiring Java" that irks most (I've
ranted myself on the Subsume corporate site). It means that I can't
reuse the business objects I create for my regular apps (I am *not*
going to use Java to write a desktop app; even something simple like
TextEdit blew as a Java app!) in building a web site. That's a big
miss, and if Apple ever completely drops ObjC support from WebObjects
I'm quite certain they'll find more people flocking to GNUstep Web
rather than porting perfectly good code to Java, and paying Apple for
the privledge.
John C. Randolph
Frederic Stark wrote:
>
> Furture of objc is much better shaped now than 2 years ago, when apple wanted to kill it.
That was before NeXT had consolidated its takeover of Apple.
-jcr
Stan Shebs
>
> >Is there a possibility Apple could do something with it
> > making it a Java alternative on all platforms (make the syntax more like
> > C++/java, but make it compiled not interpreted, perhaps)?
>
> Not likely. Apple floated the idea of a new syntax for Obj-C that
> looked like
> Java, and we made sure that the so-called "modern syntax" got put up against
> the wall and shot through the head.
It's not quite dead yet! - try cc -fmodern-objc-syntax on your OS X
system. But we're definitely not moving those patches to the
GCC 3.0-based compiler that's in the works.
Stan Shebs
sh...@apple.com
John C. Randolph
Glad to hear it.
-jcr
David Stes
On Mon, 26 Feb 2001, John C. Randolph wrote:
> > > Not likely. Apple floated the idea of a new syntax for Obj-C that
> > > looked like
> > > Java, and we made sure that the so-called "modern syntax" got put up against
> > > the wall and shot through the head.
> >
> > It's not quite dead yet! - try cc -fmodern-objc-syntax on your OS X
> > system.
>
> Glad to hear it.
Is this truly what we want ? I could accept the idea of an alternative
syntax, but why then has it be called "modern objc syntax" ?
The name "java style objc syntax" would be more appropriate.
John C. Randolph
Who cares? It's going away, and good riddance.
-jcr
Stephen Peters
> > > > It's not quite dead yet! - try cc -fmodern-objc-syntax on your OS X
> > > > system.
> > >
> > > Glad to hear it.
> >
> > Is this truly what we want ? [...]
> Who cares? It's going away, and good riddance.
Ah, John -- you missed David's clever attempt to make you look like
you wanted the `modern' syntax. Note that he removed Stan's note that
he wasn't moving it into GCC 3.0, thus making it look like you were
pleased about the syntax, not about its death.
Sometimes David can be a real wanker. :-)
--
Stephen L. Peters por...@portnoy.org
PGP fingerprint: A1BF 5A81 03E7 47CE 71E0 3BD4 8DA6 9268 5BB6 4BBE
"Poodle: The other white meat." -- Sherman, Sherman's Lagoon
David Stes
>
> > Who cares? It's going away, and good riddance.
>
> Ah, John -- you missed David's clever attempt to make you look like
> you wanted the `modern' syntax.
You still write `modern'.
I'd greatly prefer you'd say 'java-style syntax'.
I've seen over the last 15 years various attempts of NeXT (and now
Apple) to fuck up Objective-C and it usually always starts with "the old
way doing such of such" and the 'new modern way is tit or tat'.
John C. Randolph
David,
Get some competent professional help.
-jcr
David Stes
>
> David,
>
> Get some competent professional help.
You can't get the words the 'obsolete syntax from the old Apple
compiler' over your lips, can you :-)
Stephen Peters
> Stephen Peters wrote:
> >
> > Ah, John -- you missed David's clever attempt to make you look like
> > you wanted the `modern' syntax.
>
> You still write `modern'.
Yes, and I also put it in quotes. You might have noticed that some
people use quotes when they're directly copying text from somewhere
else -- such as the compiler flag being used by Apple.
> I'd greatly prefer you'd say 'java-style syntax'.
Well, we all have our crosses to bear. For example, I'd greatly
prefer that you not selectively edit other people's statements in an
effort to mislead readers. Apparently, I'm doomed to disappointment.
David Stes
>
> For example, I'd greatly
> prefer that you not selectively edit other people's statements in an
> effort to mislead readers.
If there's any attempt to mislead people then it is by using words such
as 'modern'.
'modern' is a trick used by salespeople and marketing departements in an
effort to depict the people who 'still' use the 'old' way as 'obsolete'.
Michael Ash
wrote:
>Michael Ash wrote:
>>
>> The "obsolete syntax from the old Apple compiler" is activated using a
>> flag that contains the word "modern".
>
>Actually the modern syntax is the [] syntax.
>
>The bracket syntax is "modern" and the syntax that Apple proposed to
>replace the [] syntax is "obsolete".
Yes, we all know that, David. I think everybody realizes that we all
know that except you, as well.
Nobody is claiming that Apple's syntax is good or modern or anything
like that. The only thing we're claiming is that the compiler flag that
you use to turn it on contains the character string "modern". Do you
refute that?
>If Apple has some code that is still using their obsolete Java-style
>syntax, then they should convert it to the modern [] syntax
Given that it never caught on, I'd be surprised if they had any.
--
"From now on, we live in a world where man has walked on the moon.
And it's not a miracle, we just decided to go." -- Jim Lovell
Mike Ash - <http://www.mikeash.com/>, <mailto:ma...@mikeash.com>
David Stes
On Tue, 27 Feb 2001, Michael Ash wrote:
> Nobody is claiming that Apple's syntax is good or modern or anything
> like that. The only thing we're claiming is that the compiler flag that
> you use to turn it on contains the character string "modern". Do you
> refute that?
If the compiler flag contains the character string "modern" then that
implies that Apple is trying to call it modern.
Hence : Apple considers [ myObject foo ] the "old" syntax
Hence : Apple considers myObject.foo() the "modern" or "future" syntax.
Donald A. Yacktman
>
>On Tue, 27 Feb 2001, Michael Ash wrote:
>
>> Nobody is claiming that Apple's syntax is good or modern or anything
>> like that. The only thing we're claiming is that the compiler flag that
>> you use to turn it on contains the character string "modern". Do you
>> refute that?
>
>If the compiler flag contains the character string "modern" then that
>implies that Apple is trying to call it modern.
>
>Hence : Apple considers [ myObject foo ] the "old" syntax
Actually, Apple calls it "classic" syntax.
>Hence : Apple considers myObject.foo() the "modern" or "future" syntax.
They have never called it "future", though they do call it "modern".
From Webster's Dictionary:
1mod*ern \'ma¨d-ern, ‹'ma¨d-(e-)ren\ adj
1a: of, relating to, or characteristic of a period extending
from a relevant remote past to the present time
b: of, relating to, or characteristic of the present or the
immediate past: CONTEMPORARY
2: involving recent techniques, methods, or ideas: UP-TO-DATE
3 cap: of, relating to, or having the characteristics of
the present or most recent period of development of a
language syn see NEW
I believe that this is the third definition in which they mean "modern" -- it
is a newer syntax, and was certainly developed more recently than "classic"
syntax. So calling it modern is certainly reasonable by that definition.
However, the name was invented by the marketing people as opposed to the
technical people and was obviously intended to have a more subtle effect.
Accuracy is never the top priority of marketers in my experience. I suspect
that they either wanted to get people to think that "classic" syntax is bad
and for old farts only in the hopes they could bury it forever or they wanted
the ones clamoring for Java to feel comfortable that this "new" syntax would
be around for a long time to assuage their fears of what they considered to
be a bizarre-looking syntax. Either way, I thought it a terribly stupid move
and I've always hated the name.
Frankly, though, I don't give a damn what Apple calls their new syntax. I,
and many other Apple developers, inissist upon and will continue to call it
for what it is: bulls*** syntax.
And I'm glad to hear that it is going to go away. As JCR says, GOOD
RIDDANCE. I won't miss it, and I can't imagine that anyone will.
Oh, and on the flipside, given how "modern" is an accurate name for this
syntax, I propose that we pull the same stunt in reverse. Let's make a
preprocessor that lets us write Java code using an Objective-C like syntax.
We can call it the "Modern Java Syntax". Then maybe I'd be more willing to
write Java code when occasion forces me, kicking and screaming, to do so.
Well, I like the idea anyway...
--
Later,
Don Yacktman
d...@misckit.com
Michael Ash
<st...@pandora.be> wrote:
>On Tue, 27 Feb 2001, Michael Ash wrote:
>
>> Nobody is claiming that Apple's syntax is good or modern or anything
>> like that. The only thing we're claiming is that the compiler flag that
>> you use to turn it on contains the character string "modern". Do you
>> refute that?
>
>If the compiler flag contains the character string "modern" then that
>implies that Apple is trying to call it modern.
It implies that Apple *was* trying to call it modern. The name is
obviously a legacy holdover. As evidence for this view, I submit firstly
that nobody uses it, and secondly that it will be gone in the next
compiler release.
They screwed up. They realized it. They're ditching it. Get over it.
Martin Klocke
David Stes schrieb:
>
> Martin Klocke wrote:
> >
> > What's that stuff you're inhaling/smoking/smelling/injecting?
>
> It's called "common sense" and you could use some portion of it too.
Yeah, that's why my unbelievably strong common sense told me to post the
recommendation on the Watzlawick book.
It's excellent!
Martin
P.S: It's not about who did what+ when.
It's just that all the people say "look, it's good that noone uses that
crappy syntax-proposal by Apple", and you keep going on why they dare to
call it modern.
Wow
That's what I call "The pursuit of unhappiness"
Stan Shebs
>
> >If Apple has some code that is still using their obsolete Java-style
> >syntax, then they should convert it to the modern [] syntax
>
> Given that it never caught on, I'd be surprised if they had any.
There is none. In fact, when I turned it up in my audit of Apple's
compiler patches, the original author of those changes was astonished
to see it in there - he thought that it had never been incorporated.
(The work had been done under contract.)
Stan Shebs
sh...@apple.com
Petteri Kamppuri
I'm new to this group and ObjC. I really want to learn ObjC and do some
serious programming with it when Mac OS X ships.
Doc O'Leary wrote:
> As has been pointed out by others, a Java-style syntax for ObjC has
> been proposed, judged lacking, and discarded.
I read through this whole thread, but found no comment on _what_ is
lacking in the new or "modern" or what ever syntax. Why do you think it
is bad?
Why does the messaging syntax be so different from calling functions (in
plain C) when they're essentially the same thing?
What is the benefit in writing [foo bar] instead of foo.bar()? Would the
current [foo bar] way still be better, even if you wouldn't have to care
about millions of lines of existing code and stuff like that?
--
petteri
mailto:petteri....@helsinki.fi
http://www.helsinki.fi/~pkamppur/
David Stes
>
> I'm new to this group and ObjC. I really want to learn ObjC and do some
> serious programming with it when Mac OS X ships.
You can already get some idea of the Objective-C language.
There is a compiler for Macintosh at :
http://users.pandora.be/stes/compiler.html
This is an Objective-C compiler for Macintosh System 7-8.
> I read through this whole thread, but found no comment on _what_ is
> lacking in the new or "modern" or what ever syntax. Why do you think it
> is bad?
>
> Why does the messaging syntax be so different from calling functions (in
> plain C) when they're essentially the same thing?
>
> What is the benefit in writing [foo bar] instead of foo.bar()? Would the
> current [foo bar] way still be better, even if you wouldn't have to care
> about millions of lines of existing code and stuff like that?
Perhaps you are right. However if you make such a fundamental change,
you can simply give the new language a new name.
In fact, perhaps you are interested in TOM. TOM is a language that
makes serious changes compared to Objective-C ... and consistently with
that fact, the language was given a new name.
Stan Shebs
>
> Doc O'Leary wrote:
>
> > As has been pointed out by others, a Java-style syntax for ObjC has
> > been proposed, judged lacking, and discarded.
>
> I read through this whole thread, but found no comment on _what_ is
> lacking in the new or "modern" or what ever syntax. Why do you think it
> is bad?
It's not so much that it's "bad", but that it's "different". It would
be like saying to C programmers that "=" and "==" were stupid choices,
and that assignment should be ":=" and equality should be "=". Such a
change could actually be made to work in a C compiler, but the cost to
programmers would be monumental, and the benefit negligible. Then
imagine the even greater confusion that would reign if the alternate
syntax were controlled by a -f flag to the compiler...
I wasn't around when Apple made the boneheaded decision to try to
introduce a new syntax, but believe me, I don't miss an opportunity
to ridicule it anyway. Experience shows that there are just some
things you can't change about a programming language once you've
started down the path; the people in charge were intelligent and
should have known that. My guess is that it happened at a low
point in Apple's fortunes, and was thus motivated by a sense of
desperation. It's a good lesson; when designing languages, do the
right thing, don't try to pander to the audience.
Stan Shebs
sh...@apple.com
Donald A. Yacktman
>Doc O'Leary wrote:
>> As has been pointed out by others, a Java-style syntax for ObjC has
>> been proposed, judged lacking, and discarded.
>
>I read through this whole thread, but found no comment on _what_ is
>lacking in the new or "modern" or what ever syntax. Why do you think it
>is bad?
Lots and lots... I'll get to that in a minute. ;-)
>Why does the messaging syntax be so different from calling functions (in
>plain C) when they're essentially the same thing?
They are NOT the same thing.
A message sent with [] is just that: a message. It is NOT a function call,
and if you view it as only a function call, then you are taking a narrow view
of what is happening and that will negatively impact the designs you produce.
You have to "unlearn" the bad habits you learned with C++ (and to a lesser
degree, Java) before you can take full advantage of the richness that
Objective-C can offer you.
To elaborate a bit on the message vs. function call thing a bit...
A message has a few key components to it:
1. receiver -- who gets the message
2. sender -- who sent the message
3. name -- the "selector" or method name
4. parameters
5. transport
Now, when you send a message, Objective-C chooses what code will be executed
based upon receiver and name components. However, because the messages can
be fully realized (ie, turned into actual objects) a lot about that message
suddenly becomes very indeterminant. For example, the object that actually
gets the message may not be the one to which you originally sent the message.
(Forwarding is one example. Proxy objects are a case where almost
_everything_ gets forwarded.)
It is even possible, like with NSProxy, to have objects which cause the
transport to be changed. Now, the _default_ transport is like a local
function call. But objects can alter that into remote function calls,
delayed function calls, or even trap a message and never send it, but instead
store it later for possible execution that may never happen (like for undo).
So when you send a message with [] you are doing something very different
than if you made a function call with ->(). The function call is immediate
and cannot be intercepted; that's the C semantic. Objective-C introduces a
type of call that is incredibly dynamic and flexible, and the [] syntax keeps
this fact in your mind clearly: they are two different beasts and should NOT
be notated the same way.
Note that with C++ they really are pretty much the same, so it's fine the way
it is there. With static binding, the semantic is just that of a function
call. But again, Objective-C's semantic is much more generalized, and the
syntax serves as a reminder.
>What is the benefit in writing [foo bar] instead of foo.bar()? Would the
>current [foo bar] way still be better, even if you wouldn't have to care
>about millions of lines of existing code and stuff like that?
That's a rather loaded question, and in the example you give above, there's
certainly no readability advantage, but remember that the underlying semantic
of an Objective-C message is different...reason enough to keep the [] syntax.
But there are yet some additional advantages to the Objective-C syntax beyond
just denoting a different underlying semantic. One is in code readability.
With well chosen method and variable names your code can read almost like
English sentences. Which of these would you prefer:
window = [[NSWindow alloc]
initWithContentRect:aRect
styleMask:(NSTitledWindowMask|NSResizableWindowMask)
backing:NSBackingStoreBuffered
defer:NO
screen:aScreen];
- or -
window = NSWindow.new(aRect, (NSTitledWindowMask|NSResizableWindowMask),
NSBackingStoreBuffered, NO, aScreen);
Well, the only advantage of the latter is how much typing you have to do.
But I've found that when I'm programming, only a small proportion of my time
is actually spent typing, and that other factors besides saving keystrokes
are far more important both short- and especially long- term. So I prefer
the former. Here are just some of the reasons why...
With the method name and parameters interleaved, it is easier to tell what
the parameters are for upon immediate inspection. Because it reads so
clearly, it becomes self documenting. If you return to this code a year from
now, or are debugging someone else's code you won't have to look up the docs
to see if the parameters are in the right order or to find out what they're
for. If you remember the method name, it already tells you what the
parameters are and what order they come in, so you have less to memorize when
learning the APIs.
This isn't even the best example in favor of Objective-C because all the
parameters are of a different type, so the compiler would still be of some
help in the ->() case. But if you had several parameters of identical
type...
Still, I think you can see why some of us strongly prefer this syntax. As a
further evidence of how this makes for readable, self documenting code when
you leverage it properly, let me offer a brief account of an experience I had
while in grad school.
We were assigned to write an optimizing compiler for a language we invented
in class, and it was supposed to do several optimizations, including some
global program optimizations. Realizing the magnitude of the project, I felt
that I would be able to better implement it in Objective-C; the rest of the
class used C or C++. So I forged ahead and finished it in about a week.
The code I created was clear in its intent, in part due to the Objective-C
language syntax as noted above, and in part because I was careful to choose
my method and variable names well. This clarity was of great assistance to
me whilst coding -- bugs and flaws in my reasoning were easy to spot as I
read back through my code.
The end result was that this clarity was greatly to my advantage. This was
the last assignment of the semester. We were given two weeks to complete it.
I finished in a week. Of a class of over thirty people, I was one of only
TWO to actually complete the assignment successfully and the other guy turned
his in a day late!
The TA, during grading, was also quite impressed with the language because
(a) he'd NEVER seen the language before (and never used Smalltalk) and (b) he
could understand the code completely, from just cursory inspection, even
though comments were sparse. That's something you rarely hear happening with
C and C++ code.
So when my company is developing software, I much prefer that we use
Objective-C over Java because I know that the guy who wrote something today
might not be the guy who needs to enhance or change it tomorrow. I want code
that is immediately accessible and easy to follow. Something that doesn't
require too much training. The language can be a tool to ease this into
happening; I find that Objective-C is so simple that I can spend my time
training my people in design principles and how to name methods and variables
effectively.
Objective-C doesn't guarantee that you'll get all these benefits, and you can
write crappy code in ANY language. It won't solve all your problems, and a
crappy design or a crappy job of naming things is crap in any language,
Objective-C included. (It's clarity makes it all the more obvious when code
is crap, though...) But if you want to be disciplined about it, Objective-C
makes it a little easier to succeed with the effort. And that is something
I've really come to appreciate.
The language is also not perfect, and could benefit from some minor
improvements -- but there's actually very little I'd consider worth changing.
So even though I've been spewing out some strong advocacy, let me temper it
with the disclaimers in the predeeding two paragraphs and further emphasize
that this is all my opinion. It has been built up over many years of
experience with many languages and quite a few code bases from the very small
to the very large, so for me it has a solid foundation. Your mileage, and
opinion, may vary quite a bit and that's quite understandable...but be sure
you give the Objective-C [] syntax a fair trial or you may miss out on what
has, for me at least, been a real gem.
David Stes
>
. My guess is that it happened at a low
> point in Apple's fortunes, and was thus motivated by a sense of
> desperation.
Yeah, a desperate attempt to try to keep up an image of innovation.
They were trying to make it seem they had a clue about language and
compiler design.
We wouldn't easily believe this, but that's what they were trying to do
in their desperate situation.
Michael Ash
<petteri....@helsinki.fi> wrote:
>I read through this whole thread, but found no comment on _what_ is
>lacking in the new or "modern" or what ever syntax. Why do you think it
>is bad?
>
>Why does the messaging syntax be so different from calling functions (in
>plain C) when they're essentially the same thing?
>
>What is the benefit in writing [foo bar] instead of foo.bar()? Would the
>current [foo bar] way still be better, even if you wouldn't have to care
>about millions of lines of existing code and stuff like that?
Sending a message and calling a function are radically different. They
may appear to end up doing the same thing, but the concepts aren't
nearly the same. When you call a function, you jump to a block of code,
giving that block certain parameters. You maybe get something back. When
you send a message, you're sending it to a specific object. You don't
know exactly what it will do, or where the code is, or anything like
that. Since ObjC messaging is highly dynamic, the method could come from
class A, class B, or class Z over here. The message could be captured,
sent across a network, evaluated a thousand miles away, and the result
returned to you.
A more practical reason is that parameter type and order is much easier
to see and remember in ObjC-style message syntax. Whenever I use C++
code, I'm constantly looking up the header file to see what order the
parameters are in. With ObjC, there's a big incentive to name your
messages so that the parameters are named in the message; if you know
the message, you know the parameters, and the order.
John C. Randolph
David Stes wrote:
>
> Stan Shebs wrote:
> >
> . My guess is that it happened at a low
> > point in Apple's fortunes, and was thus motivated by a sense of
> > desperation.
>
> Yeah, a desperate attempt to try to keep up an image of innovation.
No, more like they were trying not to scare away all the C++ coders.
-jcr
Mathieu Chouinard
Please shut up.
Michael Hopkins
I second that
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/_/_/ _/_/_/ _/_/_/ ACS Consultancy
_/ _/ _/ _/ _/
_/_/_/_/ _/ _/_/_/ Information Sciences for Industry
_/ _/ _/ _/
_/ _/ _/_/_/ _/_/_/ Telephone/Fax: 01732~463519 (UK)
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
`All models are wrong, but some are useful' - George Box
strobe anarkhos
> Mathieu Chouinard wrote:
> >
> > David Stes wrote:
> >
> > >
> > > On Mon, 26 Feb 2001, John C. Randolph wrote:
> > >
> > >> > > Not likely. Apple floated the idea of a new syntax for Obj-C that
> > >> > > looked like
> > >> > > Java, and we made sure that the so-called "modern syntax" got put up
> > >> > > against the wall and shot through the head.
> > >> >
> > >> > It's not quite dead yet! - try cc -fmodern-objc-syntax on your OS X
> > >> > system.
> > >>
> > >> Glad to hear it.
> > >
> > > Is this truly what we want ? I could accept the idea of an alternative
> > > syntax, but why then has it be called "modern objc syntax" ?
> > >
> > > The name "java style objc syntax" would be more appropriate.
> > >
> > >
> > Please shut up.
>
> I second that
>
Third
Piercarlo Grandi
[ ... ]
I just noticed this oldish thread, and started to follow it, and then I
read a couple of bizarre claims including this one:
mail> Sending a message and calling a function are radically different.
mail> They may appear to end up doing the same thing, but the concepts
mail> aren't nearly the same. When you call a function, you jump to a
mail> block of code, giving that block certain parameters. You maybe get
mail> something back. When you send a message, you're sending it to a
mail> specific object. [ ... ]
This is a fairly good description of what happens in actor model
languages, e.g. PLANNER, or more recently Act++.
But Objective-C is not an actor model language; it is a traditional
imperative OO language, in which the above description makes no sense.
In Objective C something like '[thingie selector: arg]' is just a
dynamically selected function call, where the function is 'selector:' in
the class of 'thingie', and 'arg' is the argument list. No more, no
less.
This is a very common howler, which appears in many laughable textbooks
too; I think it is just very unfortunate that when Smalltalk-76 (the
language described in the classic Scientific American article) evolved
into Smalltalk-80 the actor model terminology was retained; Smalltalk-76
was in many ways an actor model language, Smalltalk-80 and languages
inspired by it like Objective-C are not. Smalltalk-80 was rather more
based on Interlisp and Simula-67 than PLANNER and the actor model.
The concept of function calling in Smalltalk-80 and Objective-C and C++
and practically every well known OO language around has nothing to do
with message sending semantics and has the same semantics as in any
language that supports 'virtual' (in the sense of Simula-67/C++)
function calls.
It is just traditional OO, nothing as fancy and obscure as actor model
semantics, where one sends messages to actor objects.
Erik M. Buck
Objective-C the receiver can NOT be known at compile time. This is a huge
distinction that eliminates the need for IDL, COM, SOM, and 90% of the pages
in the seminal "Design Patters Book". C++ is an abomination of a
language. The comments regarding Smalltalk/Objective-C not having a
messaging system are silly and only true if we accept the most restrictive
and ridiculous definition of messaging.
Michael Ash
pg...@sabi.Clara.co.UK (Piercarlo Grandi) wrote:
>But Objective-C is not an actor model language; it is a traditional
>imperative OO language, in which the above description makes no sense.
I'm curious. I know basically nothing about this "actor model". What is
different in such a language compared to the semantics and so forth in
ObjC?
Marcel Weiher
>The concept of function calling in Smalltalk-80 and Objective-C and C++
>and practically every well known OO language around has nothing to do
>with message sending semantics and has the same semantics as in any
>language that supports 'virtual' (in the sense of Simula-67/C++)
>function calls.
Not quite true. Apart from the issue of C++ receivers/methods having
to be known at compile-time, Objective-C retains enough information that
any message send can be captured and provided with as much fancy
semantics as you want. Optimizing for the commin case of a synchronous
message send within the same address space doesn't change the generic
nature of message sending.
Marcel
--
Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
- Alan Kay -
Steven D. Majewski
Piercarlo Grandi <pg...@sabi.Clara.co.UK> wrote:
>
>In Objective C something like '[thingie selector: arg]' is just a
>dynamically selected function call, where the function is 'selector:' in
>the class of 'thingie', and 'arg' is the argument list. No more, no
>less.
>
But that's clearly not true. It's quite a lot more than that.
Usually, there .is. a one-to-one mapping from selector to function,
but that's not always the case. They might not be a method that
corresponds to 'selector:' .
For example, a proxy object might not implement any of a set of
selectors, but would inspect each one and it's args to decide
whether to forward them (maybe for security reasons), and they
all could be implemented by a single paramaterized function --
perhaps sending a message to a remote process. ( or maybe
choose one of several remote processes to forward to. )
The proxy doesn't have to implement stubs for all of those
possible selectors -- it intercepts and reinterprets the
messages.
The 'dynamic' selection in objective-c is much more dynamic than
just a C++ vtable selection, and that's what makes it more message like.
Maybe ST-76 or other actor languages are _more_ dynamic, and maybe
you want to reserve "messaging" for a more specific behaviour,
but "No more, no less" is overstating the case.
But any messaging system is going to have a central dynamic dispatcher
somewhere to sort out who gets the messages. The fact that obj-c's
dispatcher *sometimes* jumps directly to a function that implements
the selector, rather than always sending the message to the object
can be viewed as a mere optimization.
OK -- "sometimes" is the usual case, but you aren't limited to
the usual optimized case -- which is what the original message
was getting at, I think: That if you think in terms of the message
abstraction, it opens up a lot of possibilities that aren't
inherent in a more restricted dynamic dispatch.
-- Steve Majewski
Piercarlo Grandi
>>> D. Majewski) said:
sdm7g> In article <yf3puec...@sabi.ClaraNET.co.UK>,
sdm7g> Piercarlo Grandi <pg...@sabi.Clara.co.UK> wrote:
>> In Objective C something like '[thingie selector: arg]' is just a
>> dynamically selected function call, where the function is 'selector:' in
>> the class of 'thingie', and 'arg' is the argument list. No more, no
>> less.
sdm7g> But that's clearly not true. It's quite a lot more than that.
Oh please! It's exactly like that, no more, no less: even the
implementation of a method is exactly identical to a function
definition...
If one looks at the output of an Objective-C to C preprocessor one can
see that the implementation actually mirrors the description above
exactly, as something like:
[anObject selector: arg1 and: arg2];
becomes something like (a bit more optimised usually):
const aFunctionPtr methodPtr = findMethod(classOf(anObject),"selector:and:");
(*methodPtr)(anObject,arg1,arg2);
that is a function is located and applied to a parameter list.
sdm7g> Usually, there .is. a one-to-one mapping from selector to
sdm7g> function, but that's not always the case. They might not be a
sdm7g> method that corresponds to 'selector:' .
That's just because the implementation of the function is dynamically
selected, given the type of the first argument and the function name
(the selector).
The ability to dynamically resolve a selector to a procedure which is
then applied to an argument list is a very different thing from sending
a message to an object.
Lots of people, and even widely read textbooks, abuse the latter
terminology when applying it to Smalltalk-80 or Java or Objective-C.
Note of these language is message-based nor prototype based.
sdm7g> For example, a proxy object might not implement any of a set of
sdm7g> selectors, but would inspect each one and it's args to decide
sdm7g> whether to forward them (maybe for security reasons), and they
sdm7g> all could be implemented by a single paramaterized function --
sdm7g> perhaps sending a message to a remote process. ( or maybe choose
sdm7g> one of several remote processes to forward to. )
That's a totally different thing: it's just what has come to be known as
reflection, and is present in a lot of other languages, e.g. Java.
That Objective-C supports reflection (the original Brad Cox definition
wasn't that reflective, NeXT and Apple added more and more reflective
abilities) is a feature entirely independent from being based on the
applicative model and not the actor model.
The semantics of Objective-C, even with reflection, remain totally
applicative, and not at all based on sending messages to objects.
[ ... ]
sdm7g> Maybe ST-76 or other actor languages are _more_ dynamic, and maybe
sdm7g> you want to reserve "messaging" for a more specific behaviour,
It's not an issue of "_more_ dynamic", it's that there is a very
specific model of computation that uses message passing, called the
actor model, and it is completely different from the applicative model
on which Objective-C, Java, C, FORTRAN, Smalltalk-80, LISP, etc. are all
based. It is as different from the applicative model as are the von
Neumann, or the logic programming, or the LINDA models of computation.
I ave found a few nice online descriptions:
http://LCS.WWW.Media.MIT.edu/people/lieber/Lieberary/OOP/Act-1/Concurrent-OOP-in-Act-1.html
http://theory.Stanford.edu/people/jcm/cs358-96/actors.html
http://IC-WWW.ARC.NASA.gov/ic/darwin/oif/leo/filman/text/dpl/hewitt.pdf
Now Objective C uses dynamic overloading, just like C++ and Java, and
just like Java (or several other languages) in addition to C++ it
supports reflection, but the model of computation is still applicative
(computation proceeds as a series of [dynamically resolved] procedure
invocations) not actor (messages are sent to objects) like.
sdm7g> but "No more, no less" is overstating the case. But any messaging
sdm7g> system is going to have a central dynamic dispatcher somewhere to
sdm7g> sort out who gets the messages. The fact that obj-c's dispatcher
sdm7g> *sometimes* jumps directly to a function that implements the
sdm7g> selector, rather than always sending the message to the object
sdm7g> can be viewed as a mere optimization.
In fact Objective-C _never ever_ sends a message to an object -- objects
are just data in Objective-C. Have you ever used the language? There is
simply no way to define per-object behaviour or to send a message to an
object in Objective-C.
All you can do is to define functions as part of classes, and apply
these functions (after locating them via a class-selector table) to
instances of the 'struct' defined in the class they are declared in. No
more, no less.
Something like: '[aMatrix times: bMatrix]' is just a sort of infix
notation for 'times(aMatrix,bMatrix)' where the selector 'times'
resolves to a specific function implementation depending on the type of
its first argument, and that's it.
In Objective-C methods are a per-class, not per-object attribute
(Objective-C is class based OO, not prototype based OO), and each and
every the per-class method is a procedure that is applied to a parameter
list of which the first argument is a class instance; it never happens
that the parameter list is sent as a message to a specific object, which
is what actor languages actually do.
When an Objective-C application is distributed, the runtime system may
(actually must) rely on an actor-like substrate to implement what are
still [remote] procedure calls, but that's an implementation detail.
PS This is one of my terminology pet peeves: the other one is that in
C++ the word "object" means "memory area" instead of "class
instance". Both have had often fatal consequences for those trying
to understand OO and C++ or Objective-C.
Piercarlo Grandi
mail> In article <yf3puec...@sabi.ClaraNET.co.UK>,
mail> pg...@sabi.Clara.co.UK (Piercarlo Grandi) wrote:
>> But Objective-C is not an actor model language; it is a traditional
>> imperative OO language, in which the above description makes no sense.
mail> I'm curious. I know basically nothing about this "actor
mail> model". What is different in such a language compared to the
mail> semantics and so forth in ObjC?
Well, everything; for example it is impossible to define procedures in
an actor language, nor does it have assignment, nor does it have
classes, and so on. Just about the only similarity is that both support
OO via encapsulation, just like there are OO logic programming systems
and OO von Neumann systems (capability archirtectures).
The difference is not merely one of features, but one of how sees the
semantics of computation.
In order to define a model of computation one must define primitive
entities and primitive operations; for example in the Turing-machine
model of computation primitive entities are an infinite tape, tape
slots and a read/write head, and primitive operations include move the
head to a slot, read a slot, write a slot; in the von Neumann model of
computation one has memory slots, and the ability to execute a memory
slot, to read and write a memory slot from another one.
In the applicative model (LISP, C, ML, Objective-C, Smalltalk-80, C++,
FORTRAN, etc.) one has values and functions, and names that identify
them, and one can combine functions into new functions, or apply
functions to values which the returns a value or a function, and
allow, depending on the details of the language, various other
operations on functions and values. There are two variants of the
applicative model, the imperative one, that represents state by using
``special'' values called references, and the functional one, that
represents state by using ``special'' functions called monads or
streams etc.
All this said, in the actor model the primitive entities are actors; an
actor is defined by a set of actors it knows, called its acquaintances,
and by the a script. Computation happens when an actors sends a message
to another actor (the script is the run and it parses the messages and
acts on it), or when an actor creates a new actor, or when an actor
replaces itself with another actor.
In the actor model it is impossible to define functions, or classes, or
selectors, or methods, or variables; each actor has only one script, is
immutable, is unique, and interacts with its acquaintances only by
sending and receiving messages. A message sent from A to B is not
necessarily followed by a message sent from B back to A; message sends,
as the name implies, are just unidirectional; the message may be
forwarded by B to C, and then perhaps C sends a message to A, or perhaps
not.
In Objective-C none of this happens; the semantics are strictly those of
defining functions in groups (classes) defined by all functions in the
group operating on [the representation of] values of the same type, and
applying those functions to those values.
The resolution of a function symbol (selector) to a function
implementation (method) may happen dynamically, and the symbol tables
may be inspected dynamically too (reflection), just like in Java or
Smalltalk-80, but these are just flavours of the same semantics, which
are function based.
Visionary Mike
news:yf3lmoz...@sabi.ClaraNET.co.UK...
> The semantics of Objective-C, even with reflection, remain totally
> applicative, and not at all based on sending messages to objects.
Doesn't it really depend on how you look at it? Yes, if you look at the
internals of ObjC, it's just function pointers and argument stacks, but if
you look at the language semantics, can't you call that message passing?
Sure, objects don't contain methods directly, they are defined in their
class. There are times that this may be useful, as in a prototype language,
but I could see it getting really hairy.
> In fact Objective-C _never ever_ sends a message to an object -- objects
> are just data in Objective-C. Have you ever used the language? There is
> simply no way to define per-object behaviour or to send a message to an
> object in Objective-C.
Would Self be a pure 'message based' language? I believe it's a fully
prototype based language, where instances are merely copies of other
objects, and can be redefined.
Mike
"Piercarlo Grandi" <pg...@sabi.Clara.co.UK> wrote in message
news:yf3lmoz...@sabi.ClaraNET.co.UK...
Erik M. Buck
> are just data in Objective-C. Have you ever used the language? There is
> simply no way to define per-object behaviour or to send a message to an
> object in Objective-C.
>
Do you just object to the concept of a class ?
In Objective-C
If you want to, you can create an instance of a base class that defines no
instance methods except -forward:
All messages received by such an instance will result in the code of
the -forward: method being executed.
You can implement -forward: to do anything you want including executing a
script and sending messages to other instances. You can decide what
processing to do in -forward: and you can do different processing on a per
instance basis.
In the general case, doing all processing in -forward: is not desirable and
so in the general case people use the concept of a class that defines
methods to which instances respond and let the provided run-time figure out
which method to call when a message is received.
Has it occurred to you that you are trying to redefine the meaning of
"messaging" into something obscure and irrelevant to most people. Should we
all just describe our languages as dynamic dispatching instead of messaging
to various degrees so that you can co-opt the term we are already using ?
Why should we ?
Piercarlo Grandi
>>> <visio...@chopme.hotmail.com> said:
visionary25> "Piercarlo Grandi" <pg...@sabi.Clara.co.UK> wrote in message
visionary25> news:yf3lmoz...@sabi.ClaraNET.co.UK...
>> The semantics of Objective-C, even with reflection, remain totally
>> applicative, and not at all based on sending messages to objects.
visionary25> Doesn't it really depend on how you look at it?
Not really -- the semantic properties of a language are one of the few
things that are hard to look at in diffderent ways, from a substantive
point of view -- if a language does not have variables (imperative) but
has monads (functionals) things are _really_ different, even if one
squints their eyes...
visionary25> Yes, if you look at the internals of ObjC, it's just
visionary25> function pointers and argument stacks,
Well, I was showing that just to illustrate/suggest that no message gets
sent... but the real point is semantics:
visionary25> but if you look at the language semantics, can't you call
visionary25> that message passing?
You can call that anything, as long as we understand what it is; but it
is still applying functions to argument lists and getting return values.
Messaging involves something like copying (at least conceptually) stuff
from A to B, and then A and B proceed with their work, and B does not
even have to return a result to A, just like sending packets on a
network, or sending email between mail accounts.
But my objection to the claim that Objective-C does ``message sending''
is also terminological; message sending and function application are
technical terms with very distinct, well established meanings, and to
use them to mean the same thing, or variants of the same things, as many
``popular press'' OO people do, obscures what is really going on and
confuses people; especially when somewhat exxxxagerated claims are
attached to the ``message sending'' label.
I have also found that lots of programmers are turned off by claims of
``message sending'', because they think that means that Objective-C is
really slow (as the standard meaning of the phrase implies), which it is
not; not only all that happens is really a fast, simple procedure call,
but the dynamic resolution (which can be a bit slow) is not necessary if
the compiler can infer types at runtime, which it often can (if one does
not use 'id' everywhere), and which is a major advantage of Objective-C
over completely latently typed languages like Smalltalk-80.
BTW, if anybody wonders why they have never even heard of actor
languages and why message-sending-to-objects languages are basically
amusing research topics and no more, the answer is indeed efficiency:
actor languages were invented when it looked like that one of the
possible paths of computer architecture evolution was massively
parallel machines with high bandwidth interconnects and lots of slow
processors; if this had happened languages that do have per-object
semantics and send messages between them (programs as ``societies of
actors'') would map onto them pretty well. But my PC does not have 100
10MHz CPUs, it is has one 1GHz one, and one that is heavily optimized
towards sequential processing of instructions and nested function
calls...
visionary25> Sure, objects don't contain methods directly,
They could as well (a bit inefficient though :->), but the point is that
the semantics of a method are the same for all the instances of the
class, whether or not the method is actually in the instance or the class.
In an actor language instead how a message is intepreted by the
receiving actor depends entirely on the specific actor, even if it might
happen, and it often does, that many actors have the same script (but
they might have different acquaintances for example).
visionary25> they are defined in their class. There are times that this
visionary25> may be useful, as in a prototype language, but I could see
visionary25> it getting really hairy.
Ah, but whether a language does prototypes or classes is not an issue of
model of computation, only one of how one organizes the program.
The distinction between message sending and function application is
instead a fundamental one of how the semantics of the language are
defined, not just one of how one organizes types.
As another exmaple the whole OO idea is entirely orthogonal to the
notion of model of computation; if one just drops all the class
encapsulations in a correct OO program the program remains correct and
executes exactly as before, with exactly the same sequence of function
calls. OO is just a way to organize the source of a program, it does
affect in itself the semantics or model of computaiton at all.
Therefore there are both OO and non OO languages for the imperative,
functional, logic programming, or actor model (actually not for the
actor model: it is inherently OO).
>> In fact Objective-C _never ever_ sends a message to an object --
>> objects are just data in Objective-C. Have you ever used the
>> language? There is simply no way to define per-object behaviour or to
>> send a message to an object in Objective-C.
visionary25> Would Self be a pure 'message based' language? I believe
visionary25> it's a fully prototype based language, where instances are
visionary25> merely copies of other objects, and can be redefined.
Yes, it organizes objects that share traits not in classes, but in
collections of clones of a prototype; but it is still fully applicative,
it does not do any message sending; all methods of an objects are
functions that get applied to an argument list (of which the object
itself is always implicitly part, as the 'self' distinguished parameter).
BTW, another notion that often gets confused with the class/prototype
issue is the delegation/inheritance one, not just the
applicative/actor one: Objective-C is applicative, class and
inheritance based, and actor languages are actor, prototype and
delegation based; but other combinations are possible, e.g. there are
applicative but delegation and prototype based languages like Self, or
even applicative and delegation and class based languages (the variety
of actor languages is much smaller).
However, I was objecting to both aspects of the imaginative notion that
in Objective-C messages are sent to objects: no message gets sent, and
quite separately whatever happens (function application) is surely not
defined per-object (in Objective-C).
The real beauty of Objective-C is not the fantasy notion that ``sending
messages to objects'' somehow is so much better than tired old function
application; it is that:
1) dynamic selector-to-method (name-to-function) dispatching;
2) per-class overloading of selectors;
3) reflective abilities;
4) simplicity;
5) extension of C;
6) lightweight runtime;
provide a rather compelling combination (I would add efficiency and ease
of implementation as further qualities but they sort of implicit in
those above).
Note that the original definition of Objective-C did not have much in
the way of reflective abilities, and it still was a rather pretty
language.
Smalltalk-80 has the same linguistic features (1, 2, 3 and 4), but it is
neither C compatible (5) nor as baggage-free (6); C++ does have some
features in common (1, 2, 5) and is fairly baggage free (5) but does not
have much in the way of reflective abilities (3), and is really far from
simple (4). And so on for Java, Eiffel, Lisp, etc.
Note that being based on C is not necessarily a very good idea from an
elegance point of view, but it surely is a big practical advantage.
Objective-C is basically a good language because like C it offers a
careful balance of useful characteristics, in the context of a fairly
traditional, familiar model of computation, not because of the imaginary
use of message sending to objects.
John C. Randolph
Piercarlo Grandi wrote:
[snippage]
> Messaging involves something like copying (at least conceptually) stuff
> from A to B, and then A and B proceed with their work, and B does not
> even have to return a result to A, just like sending packets on a
> network, or sending email between mail accounts.
You can do it that way in Obj-C, and in fact that's what we *usually* do
when messaging distributed objects. If you send a message that invokes
a (oneway void) method, that's exactly the behaviour you describe.
As for copying stuff from a to b, what is the stack but a means to pass
data from one context to another?
It seems to me that you're insisting on a particularly narrow definition
of message-passing, and then claiming that Obj-C and Smalltalk don't
pass messages, because they don't work like Actor based langugages. I
say that they do indeed pass messages, which messages consist of the
reciever, the method to invoke, and the arguments to that method.
-jcr
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
pg> Messaging involves something like copying (at least conceptually)
pg> stuff from A to B, and then A and B proceed with their work, and B
pg> does not even have to return a result to A, just like sending
pg> packets on a network, or sending email between mail accounts.
jcr> You can do it that way in Obj-C,
That requires quite a bit of imagination, as it is actually impossible:
there is no expression or statement in Objective-C that does that.
Yes, such a mechanism can be clumsily simulated, and indeed it is
possible to implement a message sending system in Objective-C, just as
it is possible to implement it in C, and just as it is possible to
simulate (some flavour of) procedure calls in a message sending
language. So what? The semantics of Objective-C still require procedure
call behaviour.
jcr> and in fact that's what we *usually* do when messaging distributed
jcr> objects.
This also requires a fair bit of imagination: that's just how remote
procedure calls for Objective-C or C or any other applicative language
are usually _implemented_: but the semantics of Objective-C ``message
sends'' are _always_ those of a procedure call, even the call is
simulated using carrier pigeons or quantum entanglement or message
sending.
It seems to me pretty obvious that the model of computation of a
language and those of its runtime system can be very different, and this
does not imply that the semantics of the runtime system in one case
determine the semantics of the language itself; after all applicative
and actor languages are both implementable on a von Neumann system, but
this does not make C or PLANNER have semantics related to those of
assembler.
jcr> If you send a message that invokes a (oneway void) method,
Fantasy running riot here: there is no such thing as a oneway (void or
not) method in Objective-C: control _always_ returns to the caller of a
method (save for nonlocal jumps, but then these simply cannot happen if
one is doing message sending in an actor system).
Also, technically 'void' is still the type of the result value.
jcr> that's exactly the behaviour you describe.
More fantasy... I have reread my paragraph above, and it seems clear to
me, but let me try to rephrase it:
in a message send there is _no control transfer_, only _data
transfer_, and both the sender and the recipient can continue
executing (even if the sender may the immediately go to sleep waiting
for a reply), but in a procedure call control _necessarily_ passes
from the caller to the callee and then returns to the caller (save for
nonlocal jumps).
Now it is absolutely obvious, at least to me, that in an Objective-C
``message send'' control passes from the caller to the callee, and then
returns to the caller, whether the ``message send'' is distributed or
not, so it's a procedure call.
[ ... ]
Donald A. Yacktman
> in a message send there is _no control transfer_, only _data
> transfer_, and both the sender and the recipient can continue
> executing (even if the sender may the immediately go to sleep waiting
> for a reply), but in a procedure call control _necessarily_ passes
> from the caller to the callee and then returns to the caller (save for
> nonlocal jumps).
And John gave you a valid case where Objective-C actually sends a message,
according to this definition. Have you actually _used_ the language
yourself?.
>Now it is absolutely obvious, at least to me, that in an Objective-C
>``message send'' control passes from the caller to the callee, and then
>returns to the caller, whether the ``message send'' is distributed or
>not, so it's a procedure call.
That's "fantasy running riot". What's "obvious" to you is obviously false to
those of use who have actually USED Objective-C. You must have never used
the NeXT/Apple/GNU Distributed Objects or else you'd not make that statement
as it is incorrect. You are giving the most COMMON case, true enough, but it
is certainly NOT the ONLY case.
The NeXT/Apple/GNU (gcc) Objective-C compiler -- which is used by greater
than 90% of the ObjC programmers out there -- does allow definition of a
"oneway void" method and the semantic is that the method should be considered
asynchronous.
In the DO case John describes, both the caller and the callee have their own,
independent flow of control and if you send a oneway void message, then the
caller does NOT pass control to the callee. They both already have their own
control. The caller sends the message and then goes on it's merry way,
without waiting. The callee deals with the message when it wants, and does
what it wants to, independent of the caller.
This isn't up for argument: John and I have both used DO, and that's how it
works: just like you say a message should work. Your insistence that it
doesn't work that way when we have SEEN it work that way is utterly ludicrous
fantasy from our point of view. Plus, the syntax for sending a message of DO
is the same for local objects. Unless you ask, you don't know where that
message will go, and there's no guarantee that it will have the semantic you
ascribe (or any other semantic, either, for that matter) since the
Objective-C dispatcher is extensible.
In a local example, the message could be trapped and delayed for later
execution. It could even be saved on disk for later replay. Again, the
procedure call semantic is by far the most common, and Objective-C optimized
for it, but it is NOT the only semantic and assuming that it is the only
semantic is not a good idea as it will severely limit what you can accomplish
with the language.
I honestly don't think it can be stated any more clearly than this. The way
this stuff works in reality is, to me, obviously counter to what you are
claiming (which, as you wrote it, is clear to me; I understand plainly what
you're saying and it is wrong: Objective-C doesn't always work that way).
You really should just give it up before you get thrown in the kook corner
with David Stes.
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Wed, 18 Apr 2001 15:24:26 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
>
> [ ... ]
>
> pg> Messaging involves something like copying (at least conceptually)
> pg> stuff from A to B, and then A and B proceed with their work, and B
> pg> does not even have to return a result to A, just like sending
> pg> packets on a network, or sending email between mail accounts.
>
> jcr> You can do it that way in Obj-C,
>
> That requires quite a bit of imagination, as it is actually impossible:
> there is no expression or statement in Objective-C that does that.
Yes there is, and it looks like this:
[<receiver> <message>]
Am I going too fast for you?
> Yes, such a mechanism can be clumsily simulated, and indeed it is
> possible to implement a message sending system in Objective-C, just as
> it is possible to implement it in C, and just as it is possible to
> simulate (some flavour of) procedure calls in a message sending
> language. So what? The semantics of Objective-C still require procedure
> call behaviour.
>
> jcr> and in fact that's what we *usually* do when messaging distributed
> jcr> objects.
>
> This also requires a fair bit of imagination: that's just how remote
> procedure calls for Objective-C or C or any other applicative language
> are usually _implemented_: but the semantics of Objective-C ``message
> sends'' are _always_ those of a procedure call, even the call is
> simulated using carrier pigeons or quantum entanglement or message
> sending.
No, you have this exactly backwards: the semantics of an Objective-C
message are *always* that of a message, even though the message send is
implemented using a procedure call.
> It seems to me pretty obvious that the model of computation of a
> language and those of its runtime system can be very different, and this
> does not imply that the semantics of the runtime system in one case
> determine the semantics of the language itself; after all applicative
> and actor languages are both implementable on a von Neumann system, but
> this does not make C or PLANNER have semantics related to those of
> assembler.
>
> jcr> If you send a message that invokes a (oneway void) method,
>
> Fantasy running riot here: there is no such thing as a oneway (void or
> not) method in Objective-C: control _always_ returns to the caller of a
> method (save for nonlocal jumps, but then these simply cannot happen if
> one is doing message sending in an actor system).
Pomposity running riot here: there is indeed such a thing as a oneway
method in Obj-C. Look up the docs on Apple or GNU Distributed Objects
for the details.
> Also, technically 'void' is still the type of the result value.
No, "void" is the *absence* of a result value.
> jcr> that's exactly the behaviour you describe.
>
> More fantasy... I have reread my paragraph above, and it seems clear to
> me, but let me try to rephrase it:
Sure it's clear: It's just wrong.
> in a message send there is _no control transfer_, only _data
> transfer_, and both the sender and the recipient can continue
> executing (even if the sender may the immediately go to sleep waiting
> for a reply), but in a procedure call control _necessarily_ passes
> from the caller to the callee and then returns to the caller (save for
> nonlocal jumps).
...or messages to objects in other threads, or in other processes, or on
other hosts.
> Now it is absolutely obvious, at least to me, that in an Objective-C
> ``message send'' control passes from the caller to the callee, and then
> returns to the caller, whether the ``message send'' is distributed or
> not, so it's a procedure call.
It's obvious to the people on this newsgroup who've used Obj-C, and done
the things that you state are impossible in Obj-C, that you are out of
your depth when discusing this language.
Feel free to get back to us when you've done a bit of study. Until
then, you're not someone I need take seriously.
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Wed, 18 Apr 2001 15:24:26 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
>
> [ ... ]
>
> pg> Messaging involves something like copying (at least conceptually)
> pg> stuff from A to B, and then A and B proceed with their work, and B
> pg> does not even have to return a result to A, just like sending
> pg> packets on a network, or sending email between mail accounts.
>
> jcr> You can do it that way in Obj-C,
>
> That requires quite a bit of imagination, as it is actually impossible:
> there is no expression or statement in Objective-C that does that.
Yes there is, and it looks like this:
[<receiver> <message>]
Am I going too fast for you?
> Yes, such a mechanism can be clumsily simulated, and indeed it is
> possible to implement a message sending system in Objective-C, just as
> it is possible to implement it in C, and just as it is possible to
> simulate (some flavour of) procedure calls in a message sending
> language. So what? The semantics of Objective-C still require procedure
> call behaviour.
>
> jcr> and in fact that's what we *usually* do when messaging distributed
> jcr> objects.
>
> This also requires a fair bit of imagination: that's just how remote
> procedure calls for Objective-C or C or any other applicative language
> are usually _implemented_: but the semantics of Objective-C ``message
> sends'' are _always_ those of a procedure call, even the call is
> simulated using carrier pigeons or quantum entanglement or message
> sending.
No, you have this exactly backwards: the semantics of an Objective-C
message are *always* that of a message, even though the message send is
implemented using a procedure call.
> It seems to me pretty obvious that the model of computation of a
> language and those of its runtime system can be very different, and this
> does not imply that the semantics of the runtime system in one case
> determine the semantics of the language itself; after all applicative
> and actor languages are both implementable on a von Neumann system, but
> this does not make C or PLANNER have semantics related to those of
> assembler.
>
> jcr> If you send a message that invokes a (oneway void) method,
>
> Fantasy running riot here: there is no such thing as a oneway (void or
> not) method in Objective-C: control _always_ returns to the caller of a
> method (save for nonlocal jumps, but then these simply cannot happen if
> one is doing message sending in an actor system).
Pomposity running riot here: there is indeed such a thing as a oneway
method in Obj-C. Look up the docs on Apple or GNU Distributed Objects
for the details.
> Also, technically 'void' is still the type of the result value.
No, "void" is the *absence* of a result value.
> jcr> that's exactly the behaviour you describe.
>
> More fantasy... I have reread my paragraph above, and it seems clear to
> me, but let me try to rephrase it:
Sure it's clear: However, your claim that this never happens in Obj-C
is simply wrong.
> in a message send there is _no control transfer_, only _data
> transfer_, and both the sender and the recipient can continue
> executing (even if the sender may the immediately go to sleep waiting
> for a reply), but in a procedure call control _necessarily_ passes
> from the caller to the callee and then returns to the caller (save for
> nonlocal jumps).
...or messages to objects in other threads, or in other processes, or on
other hosts.
> Now it is absolutely obvious, at least to me, that in an Objective-C
> ``message send'' control passes from the caller to the callee, and then
> returns to the caller, whether the ``message send'' is distributed or
> not, so it's a procedure call.
It's obvious to the people on this newsgroup who've used Obj-C, and done
Petteri Kamppuri
> Feel free to get back to us when you've done a bit of study. Until
> then, you're not someone I need take seriously.
Why is it so hard for people to be constructive in this newsgroup?
It is obvious that Piercarlo Grandi isn't so familiar with ObjC, that he
would know about all details of distributed objects (DO). All that he
said was true for programs not using DO. Or was it? I don't know ObjC
that well, that I could claim that. In his mind was was telling the
truth and couldn't understand your point of view, because he doesn't
understand DO.
Now, using DO changes the semantics of the language a bit. One can
specify special messages that use actual message passing semantics,
compared to the normal function call semantics.
I hate to read this group, because many writers are unwilling to try to
really understand others. They think they are ultimately right. And they
all are, looking from _their point of view_. But sometimes they lack
some knowledge (as Piercarlo in this case), and nicely explaining that
missing information would be much better than just saying: "No, you're
wrong and stupid. I am right." And this comment really goes to the
"Everybody vs. Stes" mentality.
We are all smart people here (hey, why else would we be interested in
ObjC?), so please lets try to act like smart people. Be constructive,
help others understand what they don't yet undestand and try to have a
positive attitude for others.
I hope this message doesn't irritate you too much, and excuse my bad
Engish, but hopefully you get the point.
John C. Randolph
Petteri Kamppuri wrote:
>
> "John C. Randolph" wrote:
>
> > Feel free to get back to us when you've done a bit of study. Until
> > then, you're not someone I need take seriously.
>
> Why is it so hard for people to be constructive in this newsgroup?
Petteri, take a look back in the thread. I took the gloves off when
Grandi dismissed my statements as "fantasy running riot."
I've been through enough of that kind of tripe with Stes, and I'm not
about to take it from anyone else. If that bothers you, then stick me
in your killfile: I won't mind.
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> after all applicative
> and actor languages are both implementable on a von Neumann system, but
> this does not make C or PLANNER have semantics related to those of
> assembler.
It would appear that you're also quite unfamiliar with C, or you'd know
that C has semantics which are very much like an assembler: the PDP-11
assembler, to be precise.
-jcr
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
jcr> Piercarlo Grandi wrote:
>> after all applicative and actor languages are both implementable on a
>> von Neumann system, but this does not make C or PLANNER have
>> semantics related to those of assembler.
jcr> It would appear that you're also quite unfamiliar with C, or
jcr> you'd know that C has semantics which are very much like an
jcr> assembler: the PDP-11 assembler, to be precise.
This discussion is only on topic peripherally, but it might serve to
illustrate the general idea of what is a difference in semantics...
While the semantic level of C is close to that of PDP-11 assembler, the
semantics of C have nothing to do with those of PDP-11 assembler.
They were designed to be easily mappable (hence the relatively low level
of C, and some oddities) onto the semantics of PDP-11 assembler, and
were designed to be _implementable_ on stock von Neumann style
computers, and this is very different concept from the one you express
above (``easily implementable'' != "very much like"):
* C semantics are defined in terms of functions, blocks, lexically
scoped identifiers, types, variables, pointers, arrays, values,
function instantiation, control structures, assignment, expressions
and other typical high level language primitives.
* the PDP-11 CPU has _none_ of these, but it has instead registers,
memory words, bitpatterns, operations involving registers, loads and
stores and various types of jumps, like any good von Neumann style
computer.
Thus C and the PDP-11 implement completely different models of
computation, which can well be mapped onto one another, but it takes a
compiler and a runtime system to implement that, and that involves still
quite a bit of work, even if C is fairly low level for an high level
language.
For example, to stay a bit within topic, the model of computation of
the PDP-11 is not applicative, so to implement C function calling one
must map parameters and local variables onto stack words, and expand a
call into a jump with save the PC; but this does not mean that the
semantics of the PDP-11 and those of C are at all similar, simply that
they are easily compatible.
As another example C was designed without nested functions, which are
common in other applicative languages, mostly because the PDP-11 does
not have hardware support for displays or similar nested scope
implementation techniques; but avoiding in one model of computation
features that are expensive to map to another does not mean tha the
two models are similar...
As another example, C semantics forbid the application of functions
defined on one type to values of another tpe; but the semantics of
PDP-11 permit the application of nearly any instruction on nearly any
bitpattern, no matter how inappriate that is. As a particularly
galring case, one can compute and store bitpatterns into memory words
in the PDP-11 assemebler and then execute them (the essential
characteristic of the von Neumann model of computation) and this is
utterly forbidden in C.
An ancient language like Wirth's PL/360 might have a model of
computation similar to the von Neumann one, in that it looked a bit
like C where the only allowed statement is GNU's '__asm__', but not C.
Even BCPL from which is derived, did not really a von Neumann style
model of computaiton, even if it was even lower level than C, and
rather closer to the machine level.
C is a Machine Oriented High Level Language, and PDP-11 assembler is a
Machine Language, and the "High Level" bit is the one that implies that
the semantics of C are very different from those of the PDP-11.
Conversely, C and Objective C have almost exactly the same model of
computation, and their biggest difference is a very different way of
organizing program texts, enabled by availability of classes.
Piercarlo Grandi
>>> said:
don> pg...@sabi.Clara.co.UK (Piercarlo Grandi) wrote:
[ ... ]
pg> in a message send there is _no control transfer_, only _data
pg> transfer_, and both the sender and the recipient can continue
pg> executing (even if the sender may the immediately go to sleep
pg> waiting for a reply), but in a procedure call control _necessarily_
pg> passes from the caller to the callee and then returns to the caller
pg> (save for nonlocal jumps).
[ ... ]
pg> Now it is absolutely obvious, at least to me, that in an Objective C
pg> ``message send'' control passes from the caller to the callee, and
pg> then returns to the caller, whether the ``message send'' is
pg> distributed or not, so it's a procedure call.
don> That's "fantasy running riot". What's "obvious" to you is
don> obviously false to those of use who have actually USED Objective C.
don> You must have never used the NeXT/Apple/GNU Distributed Objects or
don> else you'd not make that statement as it is incorrect.
I may be remebering wrong, but I have been discussing the properties of
Objective C (generically by default, given the existence of various
dialects), not those of NeXT/Apple/GNU DO or any other specific
distributed scheme...
Starting an argument by mentioning experience of "Objective C" and then
switching as effortlessly as that to discussing "NeXT/Apple/GNU
Distributed Objects" is not correct; the two subjects are actually very
different, and one cannot apply a conclusion valid for the NeXTStep (and
compatible) DO scheme to the semantics of one of the languages it can be
used from.
don> You are giving the most COMMON case, true enough,
Even if just this were the case, the claim I am disputing is that saying
``message sending'' in the context of Objective C does actually mean
that Objective C is based on sending messages, when at most it can use
libraries that do send messages, while maintaining applicative semantics:
pg> When an Objective C application is distributed, the runtime system
pg> may (actually must) rely on an actor-like substrate to implement
pg> what are still [remote] procedure calls, but that's an
pg> implementation detail.
Let me say this another way: if Objective C was really based upon
``message sending'', there would be have been no need for NeXT to
retrofit into it NeXTStep specific extensions like 'oneway', 'in', 'out'
etc.
don> but it is certainly NOT the ONLY case.
Your statement above is based (being optimistic) on fogetting that the
semantics of a language and how some part of some particular version of
its libraries or runtime system or a related framework operate are
vastly different concepts, or of the even simpler idea that there is an
essential difference between the properties of a language and one of its
various implementations.
For example C/C++ are surely based on function call semantics, but I
hope that nobody claims it is message based because, when using the
C/C++ CORBA bindings, functions can be declared with the 'oneway void'
IDL attribute:
or because it is possible to use socket based library functions to send
datagrams; similarly, it is possible to define value returning blocks
'({ .... })' in the GNU implementation of C and therefore of GNU
Objective C, but that does not make C/C++ or Objective C valued-block
languages.
Confusions about the boundaries between the language, some of its
runtime libraries, frameworks that the language can use, and its
implementations ca have unpleasant consequences on actual programming
practice:
* confusing the properties of a language and those of the implementation
of its runtime library makes programs unduly dependent on the details
of the latter, or even of a particular release of it;
* confusing the properties of a language with those of
a particular implementation can easily make applications unportable.
I am particularly keen on these points because over many years I have
come into contact with several dialects and implementations of Objective
C and several versions of the same implementation, so I tend to have a
less NeXTStep centred view of the world than many others..
Cosnider what has happened to Smalltalk-80: its successors have been a
pretty wide spectrum of rather mutually incompatible variants (despite
slowish attempts at maintaining a standard); while relatively few
language variations have happened, the variation in frameworks has been
quite large.
Even worse, confusing ``sending messages to objects'' with dynamically
dispatched function calls has specifically bad consequences because:
* The program structures that are most maintenable with message sends
and with procedure calls are very different (two different models of
computation, with very different performance profiles too), and trying
to design a program structure suitable for message sending can result
in poor maintenability when using a programming language actually
based on function call semantics.
* Less technically, as I already mentioned, message sending looks bad
because it is often associated with low performance; claiming that
Objective C is based on message sending may turn off a lot of people;
just consider how many people incorrectly think that Objective C must
be slower than C++ because they get the impression that Objective C
must always do dynamic ``dispatching'', when C++ only does it for
'virtual' member functions.
Consider also this not irrelevant point: Objective C not only performs
so well because it is based on (potentially) easily optimisable function
calls (in some or even many cases method can be even inlined), but also
because function calling is its _only_ ``communication'' mechanism.
That all ``message sends'' actually have the semantics of dynamically
dispatched function calls means that they can be implemented for example
as:
/* [arg1 selector: arg2]; */
(*resolveSelector(classOf(arg1),"selector:"))(arg1,arg2);
which means that it is dead easy to intercept and redirect any method
call, if so desired, and this is precisely what enables all the
flexibility, including transparent distributed RPCs, for which Objective
C is so useful.
If one introduces, as some (unfortunately popular) implementations do,
ad-hoc extensions that provide other types of non-Objective C semantics,
things become rather less simple and amusing.
[ ... ]
Piercarlo Grandi
>>> <petteri....@helsinki.fi> said:
petteri.kamppuri> "John C. Randolph" wrote:
>> Feel free to get back to us when you've done a bit of study. Until
>> then, you're not someone I need take seriously.
petteri.kamppuri> Why is it so hard for people to be constructive in
petteri.kamppuri> this newsgroup?
I think that this newsgroup, like many others, is frequented by quite a
few people that mistake their limited knowledge and limited (even if
successful) experience with something very different like the facts and
the state of the art, and become angry when confronted with the
revelation that they have long fooled themselves with fancy terms like
``message sending'', and hate the bearer of the bad tidings.
One can program in Objective C fairly successfully even if one
imagines that the semantics of method invocation are that messages do
actually get sent between objects; after all whatever one thinks,
Objective C does the right thing.
Constructive contribution is about explaining things in detail and
showing how they work and why, and why the fantasies have bad
consequences, which is what I have done, and takes time and patience.
It is instead quick and easy to do otherwise; as to examples of
presenting malicious fantasies as facts, this is an excellent one:
petteri.kamppuri> It is obvious that Piercarlo Grandi isn't so familiar
petteri.kamppuri> with ObjC, that he would know about all details of
petteri.kamppuri> distributed objects (DO). All that he said was true
petteri.kamppuri> for programs not using DO. Or was it? I don't know
petteri.kamppuri> ObjC that well, that I could claim that. In his mind
petteri.kamppuri> was was telling the truth and couldn't understand your
petteri.kamppuri> point of view, because he doesn't understand DO.
Here you casually state as a fact the malicious slander that I
understand neither about Objective-C nor about Distributed Objects
(which I had not mentioned at all, it being outside the scope of this
discussion)
In fact I do know both several Objective C variants and several DO
schemes, to the point that I am even able to realize that they are very
distinct thingies, and the semantics of the language are not the same as
the semantics of the any particular DO scheme, and that some ad-hoc
language extensions that support a particular style of distributed
semantics are not the same as the language itself.
These distinction don't actually require a lot of research; there is a
fairly reasonable discussion mentioning them on the WWW at:
http://www.channelu.com/NeXT/NeXTStep/3.3/nd/Concepts/ObjectiveC/3_MoreObjC/MoreObjC.htmld/
taken straight from the NeXTStep 3.3 docs, as is pretty obvious from the
URL.
Also, if one does a little search for 'oneway void' on the WWW:
one finds that it is a construct in some version of the CORBA IDL too,
and is mentioned usually in conjunction with Distributed Objects schemes
for C/C++/Java; but nobody (I hope) claims that this means that
C/C++/Java use message sending instead or as well as function calling.
There is a fairly close CORBA mapping for Python, a language not that
dissimilar from Objective C, including support for CORBA 'oneway':
http://WWW.Informatik.HU-Berlin.DE/~loewis/python/pymap.htm
That does not mean that Python is a message sending lanmguage either.
What actually happens is that some (popular) Objective C compilers merge
a bit of the CORBA IDL preprocessor into their dialect of Objective C as
an extension; fine, but it's a rather different issue.
PS In part I am a bit annoyed by this discussion because a few years ago
I did as a research project a distributed objects scheme for
Objective C that used _neither_ message passing nor procedure calls
(by modifying the runtime), so not only I know very well about these
things, but also I am well aware that both my continuation passing
scheme and the message passing aspects of CORBA and other DO schemes
are not part of Objective C.
BTW, for amusement I searched my archives for my first USENET article
involving Objective C, and not coincidentally it was about RMG:
------------------------------------------------------------------------
From: p...@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: C++ considered disenchanting
Summary: Of course Stroustrup is a hacker, but C++ is successful
Keywords: C++ objective C adequacy
Message-ID: <2...@aber-cs.UUCP>
Date: 20 Oct 88 11:16:01 GMT
References: <20...@cs.Buffalo.EDU> <30...@mulga.oz>
X-Disclaimer: Opinions expressed are purely personal to the author
[ ... ]
A good programming environment similar to that of Smalltalk would
certainly be nice.
A group at Stanford designed a full Smalltalk like Objective C environment
called RMG for HP machines (it is fully portable however). It is even more
powerful and impressive than Smalltalk. Full colour, dynamic linking of
compiled Objective C sources, blinding speed, very sophisticated graphical
interface.
[ ... ]
------------------------------------------------------------------------
About 12 years ago, and the RMG dialect of Objective C (not the
first I had seen by then) that HP had developed already had some ad
hoc extensions, BTW.
I have also looked at the 'comp.lang.objective-c' article I can find
easily, and this, which amazingly is from Brad Cox and is actually
somewhat on topic, has popped up (from 'comp.object' though):
------------------------------------------------------------------------
From c...@stpstn.UUCP Thu May 3 16:10:46 1990
Newsgroups: comp.object
Keywords: general query, OOPS, Linda
Reply-To: c...@stpstn.UUCP (Brad Cox)
Organization: Stepstone
From: c...@stpstn.UUCP (Brad Cox)
Subject: Re: Message-Passing and Generative Communication
Date: 28 Apr 90 17:23:40 GMT
In article <17...@orstcs.CS.ORST.EDU> bu...@mist.CS.ORST.EDU (Tim Budd) writes:
>The result was to discover that the Linda primitives are much to expensive
>to be used on such a fine grain level as every message send. The system is
>unbelivably slow. Also the automatic parallelism that we had hoped for
>didn't materialize. Many many Smalltalk methods have two or more sucessive
>messages that, while they don't share data and the result from the first
>message is thrown away, still must be run in sequence.
Tim, for what its worth, the outcome of my musing on this topic lead in
a different direction, described in my IEEE Software paper, which is
close to the vision expressed in the paper by Dan Ingals et al in
the 1988? OOPSLA proceedings re: Fabrik.
To wit, suppose that we declare the Smalltalk notion of objects that
communicate synchronously via messages to be 'close enough' and not tamper
with it further. By that I mean, suppose that we accept that message
passing is an intermediate level modularity/binding technology that
tips its hat both in the direction of the Von Neuman machine
(synchronicity) and in the direction of the user (open universe model;
dynamic binding). At this intermediate level, we have the possibility
of building applications out of networks of synchronous objects via
a modularity/binding technology that I call chip-level integration
ala' Software-IC's.
But as you point out, such objects are still *passive*, in that they
lie there as limply as conventional data variables until the outside
world passes them a thread of control, which they share as subroutines,
rather than as coroutines. What Ingals did with Fabrik was to define
a higher-level kind of 'object', a data-flow module, that I'll dub a
software *card*, i.e. that which encapsulates a thread of control *and*
a collection of lower-level objects (gates, blocks, and chips). Since
these data-flow modules, these card-level objects, encapsulate their
own thread of control, it is exceedingly intuitive to manipulate them,
not with a textual language, but with the visual one (bubbles and arrows)
he used in Fabrik.
The implications of this are that programmers, as we think of programmers
today, may never build *with* non-synchronous software cards. They will
build the cards themnselves using synchronous lower-level entities of
Smalltalk, Objective-C and C++. It will be out *consumers* who will be
doing card-level programming by wiring together software cards from a
marketplace in card-level objects.
In other words, we'll be solving the programmer shortage the same
way the telephone industry solved the telephone operator shortage,
by changing software technology so that *everyone* becomes a
programmer without realizing it.
------------------------------------------------------------------------
And this is one the older 'comp.lang.objective-c' article I have saved,
which is also interesting because it documents a few variants of
implementation already 10 years ago.
------------------------------------------------------------------------
Newsgroups: comp.lang.objective-c
Reply-To: mi...@stepstone.com.UUCP (Mike Goda)
Organization: The Stepstone Corporation, Sandy Hook, CT 06482
From: mi...@stpstn.UUCP (Mike Goda)
Subject: Availability of Objective-C
Date: 23 Oct 90 10:57:50 GMT
In response to an earlier posting to the objective-c news group, someone
inquired about the commercially supported availability of Objective-C(TM)
compilers on various platforms. Well, here is the list and who you can get
it from:
Objective-C Compiler is currently available on:
-----------------------------------------------
VENDOR PLATFORM
------ --------
Stepstone Sun 3 SunOS 3.n and 4.0.n and 4.1
Stepstone Sun 386i SunOS 4.0.n
Stepstone Sun 4 SunOS 4.0.n and 4.1
Stepstone VAX stations under ULTRIX 3.0
Stepstone DEC stations under ULTRIX 2.0
Stepstone HP 9000 Series HP-UX 6.5 and 7.0
Stepstone Apollo Domain 9.7, 10.1, 10.2
IBM and Stepstone PC-AT (or compatible) DOS 3.3, 4.0.1 with MSC
IBM and Stepstone PS/2 (or compatible) OS/2 1.1 with MSC
Stepstone IBM PC-RT, PS/2 and RISC SYSTEM/6000 AIX
Stepstone Data General AViiON systems under DG/UX 4.30
Stepstone SCO UNIX System V/386 Version 3.2
NeXT NeXT
DCL Japan Sony NeWS
--
The Stepstone Corporation Michael Goda
75 Glen Rd. mi...@stepstone.com
Sandy Hook, CT 06482 uunet!stpstn!mikeg
(203) 426-1875 fax (203)270-0106
------------------------------------------------------------------------
Erik M. Buck
process space on what machine will received the message "selector" in the
following expression: [receiver selector];
Since the programmer can not always know, the programmer has to assume the
most general semantic. The most general semantic is message passing. The
object that sends the message "selector" need not block nor wait for any
return value. The sender object can proceed asynchronously. The message
may not even be delivered to any object. If "receiver" happens to be in the
same process space as the sender then a fast synchronous optimization is
applied.
Both Gnu Objective-C and Apple/NeXT Objective-C work in exactly this way.
Please do not argue that since there is no standard then only features
supported in every implementation are "part of the language". I estimate
that 99.9% of Objective-C users are using the Gnu implementation or the
Apple/NeXT implementation.
Unlike using IDL and CORBA, there is no distinction between an Objective-C
message expression to a local object and to a remote object. Objective-C
code written to send messages to an arbitrary object can not even know if
the object it is given is local or remote. There are no stubs. There are
no libraries that are not part of the "standard" runtime. Enabling
transparent message sending is not even optional. The capability is always
present. The key word oneway is part of the language grammar and not some
add-on that is preprocessed by an IDL. Every method in every object can
have the oneway declaration specifier regardless of whether instances of the
object are local or remote. There is no way at compile time to know if an
object is local or remote. There is no way at runtime to know in every case
if an object is local or remote.
You are mistaken and you are arguing to narrow a definition to the point of
absurdity.
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Sat, 21 Apr 2001 11:39:32 +0300, Petteri Kamppuri
> >>> <petteri....@helsinki.fi> said:
>
> petteri.kamppuri> "John C. Randolph" wrote:
>
> >> Feel free to get back to us when you've done a bit of study. Until
> >> then, you're not someone I need take seriously.
>
> petteri.kamppuri> Why is it so hard for people to be constructive in
> petteri.kamppuri> this newsgroup?
>
> I think that this newsgroup, like many others, is frequented by quite a
> few people that mistake their limited knowledge and limited (even if
> successful) experience with something very different like the facts and
> the state of the art, and become angry when confronted with the
> revelation that they have long fooled themselves with fancy terms like
> ``message sending'', and hate the bearer of the bad tidings.
Grandi,
Your insistence on the narrowest possible definition of
"message-sending" is not a "revelation", but simply a case of posturing.
You are not "the bearer of bad tidings", you are merely someone who is
very verbose in stating your unfounded opinions.
-jcr
Piercarlo Grandi
>>> <buck...@mcleodusa.net> said:
buck.erik> It is not possible in Objective-C to know in all cases what
buck.erik> object in what process space on what machine will received
buck.erik> the message "selector" in the following expression: [receiver
buck.erik> selector]; Since the programmer can not always know, the
buck.erik> programmer has to assume the most general semantic. The most
buck.erik> general semantic is message passing.
If this bit of weird imagination had any relationship to what Objective
C is about, then the use of the NeXTStep extensions 'in', 'out',
... would be mandatory for the relevant argument types, because without
those it is well quite hard :-> to maintain appropriate semantics in
both the same address space and the distributed case.
However the reality is that these type modifiers are not used
universally, but precisely only for those methods that are expected to
be invoked via DO/GNUStep.
buck.erik> The object that sends the message "selector" need not block
buck.erik> nor wait for any return value. The sender object can proceed
buck.erik> asynchronously.
Moreover the idea that it is objects that send messages is sheer, and
pretty strange, fantasy: I can imagine that the naive may be fooled by
the postfix '[object aSelector: anArg]' syntax into believing that it is
'object' that ``sends'' 'aSelector: anArg', but it takes pretty strong
imagination to ``see'' that objects ``send'' messages: methods are
called by other methods.
It is nonsensical to say that in Objective C an object can ``send a
message''; all ``message send'' operations happen inside the body of a
method, which is not an object, it is a procedure.
buck.erik> The message may not even be delivered to any object. If
buck.erik> "receiver" happens to be in the same process space as the
buck.erik> sender then a fast synchronous optimization is applied.
buck.erik> Both Gnu Objective-C and Apple/NeXT Objective-C work in
buck.erik> exactly this way. Please do not argue that since there is no
buck.erik> standard then only features supported in every implementation
buck.erik> are "part of the language". I estimate that 99.9% of
buck.erik> Objective-C users are using the Gnu implementation or the
buck.erik> Apple/NeXT implementation.
Then you must be part of the 0.1%, because it is absolutely clear that
GNU Objective does nothing of the sort you describe above, as it is the
common experience to those that actually use it, and debug even trivial
programs with it.
Why should people that belong to that 0.1% let their fantasy dominate
their News articles, when it would have been easy to downloaded GNU
Objective C and actually try it? It's free!
It looks like that it is time to get into ``very, very detailed
explanation mode''. Anybody who already knows about GNU Objective C can
skip the next three hundred lines :-).
For the sake of illustration, here is a little, but really really clear
experiment (the source is a a quick hack, I hpe I haven't done anything
glaringly wrong) that anybody can try in the comfort and safety of their
own home:
------------------------------------------------------------------------
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
$ cat oneWay.m
#include <string.h>
#include <malloc.h>
#include <stdio.h>
#include <objc/Object.h>
@interface OneWay: Object
{
n const char *label;
}
+ (OneWay *) new;
- (OneWay *) name: (const char *const) l;
- (const char *) name;
- (ONEWAY void) receiveMsg: (in const char *const) m pre: (in const char *const) p
forwardTo: (in OneWay *const) o1 andThenTo: (in OneWay *const) o2;
@end
@implementation OneWay
+ (OneWay *) new
{
OneWay *const o = [super new];
return o;
}
- (OneWay *) name: (const char *const) l
{
label = l;
}
- (const char *) name
{
return label;
}
- (ONEWAY void)
receiveMsg: (in const char *const) m pre: (in const char *const) p
forwardTo: (in OneWay *const) o1 andThenTo: (in OneWay *const) o2
{
char pre[16];
strcpy(pre,p); strcat(pre,"*");
fprintf(stderr,"%s %s: receiveMsg: receiving '%s'.\n",p,label,m);
if (o1 != 0)
{
fprintf(stderr,"%s %s: receiveMsg: sending to '%s'",p,label,[o1 name]);
if (o2 == 0)
fputs(".\n",stderr);
else
fprintf(stderr," and then to '%s'\n",[o2 name]);
[o1 receiveMsg: m pre: pre
forwardTo: o2 andThenTo: (OneWay *) 0];
fprintf(stderr,"%s %s: receiveMsg: sent to '%s'.\n",p,label,[o1 name]);
}
fprintf(stderr,"%s %s: receiveMsg: '%s' processed.\n",p,label,m);
}
@end
int main(int argc,char **argv)
{
OneWay *o1, *o2, *o3;
o1 = [[OneWay new] name: "o1"];
o2 = [[OneWay new] name: "o2"];
o3 = [[OneWay new] name: "o3"];
[o1 receiveMsg: "message to o1" pre: "*"
forwardTo: o2 andThenTo: o3];
[o3 receiveMsg: "message to o3" pre: "*"
forwardTo: o2 andThenTo: o3];
return 0;
}
$ ./oneWay-really
* o1: receiveMsg: receiving 'message to o1'.
* o1: receiveMsg: sending to 'o2' and then to 'o3'
** o2: receiveMsg: receiving 'message to o1'.
** o2: receiveMsg: sending to 'o3'.
*** o3: receiveMsg: receiving 'message to o1'.
*** o3: receiveMsg: 'message to o1' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o1' processed.
* o1: receiveMsg: sent to 'o2'.
* o1: receiveMsg: 'message to o1' processed.
* o3: receiveMsg: receiving 'message to o3'.
* o3: receiveMsg: sending to 'o2' and then to 'o3'
** o2: receiveMsg: receiving 'message to o3'.
** o2: receiveMsg: sending to 'o3'.
*** o3: receiveMsg: receiving 'message to o3'.
*** o3: receiveMsg: 'message to o3' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o3' processed.
* o3: receiveMsg: sent to 'o2'.
* o3: receiveMsg: 'message to o3' processed.
bash-2.04$ ./oneWay-not
* o1: receiveMsg: receiving 'message to o1'.
* o1: receiveMsg: sending to 'o2' and then to 'o3'
** o2: receiveMsg: receiving 'message to o1'.
** o2: receiveMsg: sending to 'o3'.
*** o3: receiveMsg: receiving 'message to o1'.
*** o3: receiveMsg: 'message to o1' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o1' processed.
* o1: receiveMsg: sent to 'o2'.
* o1: receiveMsg: 'message to o1' processed.
* o3: receiveMsg: receiving 'message to o3'.
* o3: receiveMsg: sending to 'o2' and then to 'o3'
** o2: receiveMsg: receiving 'message to o3'.
** o2: receiveMsg: sending to 'o3'.
*** o3: receiveMsg: receiving 'message to o3'.
*** o3: receiveMsg: 'message to o3' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o3' processed.
* o3: receiveMsg: sent to 'o2'.
* o3: receiveMsg: 'message to o3' processed.
$
------------------------------------------------------------------------
The execution trace is precisely the same whether the method is declared
'oneway' or not, and it is exactly the one corresponding to function
call semantics; this is not an accident, running GDB on the version of
the program compiled with 'oneway' demonstrates clearly what is going on:
------------------------------------------------------------------------
bash-2.04$ gdb oneWay-really
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...rw_common (): write: Function not implemented.
warning: unable to set global thread event mask
[New Thread 1024 (active)]
rw_common (): write: Function not implemented.
warning: stop_or_attach_thread: generic error
(gdb) break _i_OneWay__receiveMsg_pre_forwardTo_andThenTo_
Breakpoint 1 at 0x8048276: file oneWay.m, line 38.
(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>silent
>bt
>cont
>end
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048276 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] at oneWay.m:38
silent
bt
cont
(gdb) run
Starting program: /var/tmp/ow/oneWay-really
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6e38, _cmd=0x80aa6d8, m=0x8099954 "message to o1",
p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:41
#1 0x804859a in main (argc=1, argv=0xbffff0c4) at oneWay.m:71
#2 0x8058293 in __libc_start_main ()
* o1: receiveMsg: receiving 'message to o1'.
* o1: receiveMsg: sending to 'o2' and then to 'o3'
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f00, _cmd=0x80aa698, m=0x8099954 "message to o1",
p=0xbfffefe4 "**", o1=0x80b6f10, o2=0x0) at oneWay.m:41
#1 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6e38, _cmd=0x80aa6d8,
m=0x8099954 "message to o1", p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:53
#2 0x804859a in main (argc=1, argv=0xbffff0c4) at oneWay.m:71
#3 0x8058293 in __libc_start_main ()
** o2: receiveMsg: receiving 'message to o1'.
** o2: receiveMsg: sending to 'o3'.
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f10, _cmd=0x80aa698, m=0x8099954 "message to o1",
p=0xbfffef94 "***", o1=0x0, o2=0x0) at oneWay.m:41
#1 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f00, _cmd=0x80aa698,
m=0x8099954 "message to o1", p=0xbfffefe4 "**", o1=0x80b6f10, o2=0x0) at oneWay.m:53
#2 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6e38, _cmd=0x80aa6d8,
m=0x8099954 "message to o1", p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:53
#3 0x804859a in main (argc=1, argv=0xbffff0c4) at oneWay.m:71
#4 0x8058293 in __libc_start_main ()
*** o3: receiveMsg: receiving 'message to o1'.
*** o3: receiveMsg: 'message to o1' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o1' processed.
* o1: receiveMsg: sent to 'o2'.
* o1: receiveMsg: 'message to o1' processed.
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f10, _cmd=0x80aa6e0, m=0x8099962 "message to o3",
p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:41
#1 0x80485d9 in main (argc=1, argv=0xbffff0c4) at oneWay.m:74
#2 0x8058293 in __libc_start_main ()
* o3: receiveMsg: receiving 'message to o3'.
* o3: receiveMsg: sending to 'o2' and then to 'o3'
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f00, _cmd=0x80aa698, m=0x8099962 "message to o3",
p=0xbfffefe4 "**", o1=0x80b6f10, o2=0x0) at oneWay.m:41
#1 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f10, _cmd=0x80aa6e0,
m=0x8099962 "message to o3", p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:53
#2 0x80485d9 in main (argc=1, argv=0xbffff0c4) at oneWay.m:74
#3 0x8058293 in __libc_start_main ()
** o2: receiveMsg: receiving 'message to o3'.
** o2: receiveMsg: sending to 'o3'.
#0 -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f10, _cmd=0x80aa698, m=0x8099962 "message to o3",
p=0xbfffef94 "***", o1=0x0, o2=0x0) at oneWay.m:41
#1 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f00, _cmd=0x80aa698,
m=0x8099962 "message to o3", p=0xbfffefe4 "**", o1=0x80b6f10, o2=0x0) at oneWay.m:53
#2 0x80483a7 in -[OneWay receiveMsg:pre:forwardTo:andThenTo:] (self=0x80b6f10, _cmd=0x80aa6e0,
m=0x8099962 "message to o3", p=0x8099840 "*", o1=0x80b6f00, o2=0x80b6f10) at oneWay.m:53
#3 0x80485d9 in main (argc=1, argv=0xbffff0c4) at oneWay.m:74
#4 0x8058293 in __libc_start_main ()
*** o3: receiveMsg: receiving 'message to o3'.
*** o3: receiveMsg: 'message to o3' processed.
** o2: receiveMsg: sent to 'o3'.
** o2: receiveMsg: 'message to o3' processed.
* o3: receiveMsg: sent to 'o2'.
* o3: receiveMsg: 'message to o3' processed.
Program exited normally.
------------------------------------------------------------------------
There is no ``message'' anywhere, but surely there are instantiated
parameter lists, exactly with the same layout and form as C, with the
addition of the the two ``implicit'' parameters, 'self' and '_cmd'.
Note that this is all implementation specific stuff, but it helps for
illustration, and in any case it is _your_ argument that never mind the
language, GNU Objective C and similar implementations is what matters.
Now, let's double check, just to see why the above trace happens, and
look at the sources. One can download the sources to the very latest GNU
CC suite from:
ftp://FTP.GNU.org/pub/gnu/gcc/gcc-2.95.3/gcc-core-2.95.3.tar.gz
ftp://FTP.GNU.org/pub/gnu/gcc/gcc-2.95.3/gcc-objc-2.95.3.tar.gz
and run a simple search for "oneway":
------------------------------------------------------------------------
$ tar -xj -f gcc-core-2.95.3.tar.bz2
$ tar -xj -f gcc-objc-2.95.3.tar.bz2
$ cd gcc-2.95.3
$ find * -type f | sort | xargs egrep -i oneway
gcc/c-gperf.h: {"oneway", TYPE_QUAL, RID_ONEWAY},
gcc/c-lex.c: && (int) wordlist[i].rid <= (int) RID_ONEWAY)
gcc/c-lex.c: else if (wordlist[i].rid == RID_ONEWAY)
gcc/c-lex.c: wordlist[i].name = "oneway";
gcc/c-lex.c: ridpointers[(int) RID_ONEWAY] = get_identifier ("oneway");
gcc/c-lex.h: RID_ONEWAY,
gcc/c-parse.gperf:oneway, TYPE_QUAL, RID_ONEWAY
gcc/objc/objc-act.c: /* ONEWAY and BYCOPY, for remote object are the only method qualifiers. */
gcc/objc/objc-act.c: || node == ridpointers [(int) RID_ONEWAY]));
gcc/objc/objc-act.c: else if (ridpointers[(int) RID_ONEWAY] == TREE_VALUE (spec))
libobjc/encoding.c: || *type == _C_ONEWAY
libobjc/encoding.c: case _C_ONEWAY: res |= _F_ONEWAY; break;
libobjc/objc-features.texi:@item @code{oneway}
libobjc/objc/encoding.h:#define _C_ONEWAY 'V'
libobjc/objc/encoding.h:#define _F_ONEWAY 0x10
------------------------------------------------------------------------
From this and looking at the sources it is pretty clear that GNU
Objective C does nothing with 'oneway' beyond setting an attribute in
the description of the method. The method itself and the code generated
for it and calls to it are entirely unaffected.
Now, let's triple check, and have a look at the source for GNUStep, one
of the DO environments that can be used with GNU Objective C, and which
is an entirely distinct project and system with its own specification of
and implementation of semantics (which can be message passing based).
It is easy to download the very latest sources of the GNUStep core bits
from a mirror:
http://archive.Progeny.com/gnustep/core/gnustep-base-1.0.0.tar.gz
and to run the same search as above:
------------------------------------------------------------------------
$ tar -xz -f gnustep-base-1.0.0.tar.gz
$ cd gnustep-base-1.0.0/Source
$ find * -type f | sort | xargs egrep -i oneway
GSString.m:- (oneway void) release
NSAutoreleasePool.m:- (oneway void) release
NSBundle.m:- (oneway void) release
NSConnection.m: if ((flags & _F_ONEWAY) == 0)
NSConnection.m: if ((flags & _F_ONEWAY) == 0)
NSMethodSignature.m:- (BOOL) isOneway
NSMethodSignature.m: return (_info[0].qual & _F_ONEWAY) ? YES : NO;
NSObject.m:- (oneway void) release
NSObject.m:+ (oneway void) release
callframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
callframe.m: a non-oneway void return value, or if there are values that were
callframe.m: if ((flags & _F_ONEWAY) == 0)
callframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
callframe.m: if (out_parameters || *tmptype != _C_VOID || (flags & _F_ONEWAY) == 0)
callframe.m: /* xxx What happens with method declared "- (oneway) foo: (out int*)ip;" */
callframe.m: /* xxx Is this right? Do we also have to check _F_ONEWAY? */
callframe.m: if (*tmptype != _C_VOID || (flags & _F_ONEWAY) == 0)
callframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
cifframe.m: case _C_ONEWAY:
cifframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
cifframe.m: a non-oneway void return value, or if there are values that were
cifframe.m: if ((flags & _F_ONEWAY) == 0)
cifframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
mframe.m: case _C_ONEWAY: info->qual |= _F_ONEWAY; break;
mframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
mframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
mframe.m: a non-oneway void return value, or if there are values that were
mframe.m: if ((flags & _F_ONEWAY) == 0)
mframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
mframe.m: if (out_parameters || *tmptype != _C_VOID || (flags & _F_ONEWAY) == 0)
mframe.m: /* xxx What happens with method declared "- (oneway) foo: (out int*)ip;" */
mframe.m: /* xxx Is this right? Do we also have to check _F_ONEWAY? */
mframe.m: if (*tmptype != _C_VOID || (flags & _F_ONEWAY) == 0)
mframe.m: /* Get the type qualifiers, like IN, OUT, INOUT, ONEWAY. */
objc-gnu2next.m: || *type == _C_ONEWAY)
objc-gnu2next.m: case _C_ONEWAY: res |= _F_ONEWAY; break;
------------------------------------------------------------------------
It looks there is quite a bit more stuff than for Object C, and if one
looks at the context, it is pretty clear that the GNUStep runtime
system, written itself in Objective C, as GNUStep is an Objective C
package (it sits largely ``on top'' of GNU Objective C, it is not part
of it), does look at the flag for 'oneway' and handles it in ways that
matter to DO semantics.
So, in GNU Objective C the 'oneway' type specifier has no semantic
effect whatsoever, and method invocation has function calling semantics
in any case; in GNUStep 'oneway' does have a semantic effect.
No news here, at least for those that have used, never mind debugged,
any bit of GNU Objective C code, or used GNUStep.
All that the guys at NeXT/Apple have done with 'oneway', 'in', 'out',
etc. is to embed a little bit of a ``generic'' IDL preprocessor into GNU
Objective C; after all what an IDL preprocessor does is mostly to
produce reflective descriptions of the interfaces it parses, and since
the GNU Objective C compiler already does, already does this, they
yielded to the temptation to make it do double duty.
I personally find it somewhat distasteful, because it pollutes the
syntax of the language with elements that belong to a particular DO
scheme; the Python/CORBA binding that I have mentioned before does
something similar to GNU Objective C, but nobody claims (I hope!) that
the availability of 'oneway' in Python means that Python is based on
message sending semantics.
As to something like:
buck.erik> [ ... ] If "receiver" happens to be in the same process
buck.erik> space as the sender then a fast synchronous optimization is
buck.erik> applied. [ ... ]
things actually can go the other way round; it may be interesting to
mention in this context the Elmwood OS from Rochester IT:
http://WWW.Crowl.org/Lawrence/paper/journals/1989J-SPE-11-1029/
Piercarlo Grandi
#include <objc/Object.h>
@interface OneWay: Object
{
Piercarlo Grandi
>>> <buck...@mcleodusa.net> said:
I'll single out this bit, and perhaps it's unfair, but I think it
contains a part of the reason why some people are unware of the
distiction between messaging and applicative semantics:
buck.erik> [ ... ] If "receiver" happens to be in the same process
buck.erik> space as the sender then a fast synchronous optimization is
buck.erik> applied. [ ... ]
It's not so much, or just, the synchronous/asynchronous bit.
Messaging can be synchronous or asynchronous, e.g. Thoth/QNX, it's
mostly a buffering issu, and there is some discussion in (just a random
place that turned up in a search):
http://WWW.MHPCC.edu/training/workshop/mpi/MAIN.html
but it is always based on full copy semantics.
It is rather that applicative semantics involve instantiation of an
environment and a control transfer (creation and activation of a
closure), and messaging semantics involve none of that, only copying of
data and event handling (message arrival).
In particular C/Objective C semantics involve strictly _nested_ control
transfers (no continuations), and shared memory semantics.
CORBA/GNUStep semantics don't require strictly nested control transfers,
and don't rely on shared memory semantics, precisely because their
communication substrate is message based.
'oneway' in both is a way to use the semantics of the communication
substrate directly, and things like 'in'/'out' are _required_ for the
same reason, while C/Objective C programs, unles they use use a
distributed RPC/messaging library, can (and do) fully rely on shared
memory semantics when passing arguments or accessing globals.
Piercarlo Grandi
>>> <petteri....@helsinki.fi> said:
[ ... lots omitted ... ]
petteri.kamppuri> Now, using DO changes the semantics of the language a
petteri.kamppuri> bit. One can specify special messages that use actual
petteri.kamppuri> message passing semantics, compared to the normal
petteri.kamppuri> function call semantics. [ ... ]
On reflection I quite agree with this, and I have tried to illustrate
the difference in another article in this thread...
But I would still be a bit uneasy with the notion of "special messages
that use actual message passing semantics", because more properly it is
``special method invocations that get mapped, non-transparently, onto
message passing''.
Part of the reason is that if one really calls "message" what is a
dynamically dispatched function call, it is easy for the unwary to be
fooled by the terminology and hallucinate wildly, and I'll quote this
little fragment from some Objective-C FAQ out there:
------------------------------------------------------------------------
`-message;' declares a method called `message'. The `-' indicates
that the message can be sent to objects. A `+' instead indicates the
message can be sent to class objects.
------------------------------------------------------------------------
Very logical: if a '-' method defines a message that can be sent from an
object to another object it is natural to similarly conclude that '+'
methods define messages that can be sent to class objects -- for message
of course are always sent to some object or another, aren't they?
Never mind that one of the fundamental design decisions of Objective C
(like some versions of Smalltalk before Smalltalk-80) was _not_ to have
a metaclass system and _not_ to materialize classes as class objects!
So following a misleading terminology leads into hallucinating the
existence of class objects in a language that doesn't have them.
Besides, class objects methods, in languages that do have class
objects, are not the the same thing as class methods; because class
object methods are _not_ methods of the class, but of the metaclass,
and operate on class objects, e.g. to implement reflective facilities.
Some/many Objective C implementations do have reflective functions
that do allow querying attributes about a class, that are materialized
somewhere; but still the language does not have class objects and the
metaclasses of which they would be instances.
Marcel Weiher
>------------------------------------------------------------------------
> `-message;' declares a method called `message'. The `-' indicates
> that the message can be sent to objects. A `+' instead indicates the
> message can be sent to class objects.
>------------------------------------------------------------------------
>Very logical: if a '-' method defines a message that can be sent from an
>object to another object it is natural to similarly conclude that '+'
>methods define messages that can be sent to class objects -- for message
>of course are always sent to some object or another, aren't they?
Exactly.
>Never mind that one of the fundamental design decisions of Objective C
>(like some versions of Smalltalk before Smalltalk-80) was _not_ to have
>a metaclass system and _not_ to materialize classes as class objects!
Wrong. Although class-objects are created statically, they are
actual objects with an isa-pointer pointing to a meta-class object.
The meta-class's isa-pointer then points, hmm, somewhere, I think
to the meta-class of the root class for this class.
The following program:
#import <Foundation/Foundation.h>
main()
{
id obj=@"Hello World";
id *cur=(id*)obj;
int i;
for (i=0;i<10;i++) {
NSLog(@"cur=%x %@",cur,cur);
cur=*cur;
}
}
has this output:
Apr 23 15:22:28 a.out[1372] cur=3000 Hello World
Apr 23 15:22:28 a.out[1372] cur=8097a9dc NSConstantString
Apr 23 15:22:28 a.out[1372] cur=8097d3ac NSConstantString
Apr 23 15:22:28 a.out[1372] cur=8097c65c NSObject
Apr 23 15:22:28 a.out[1372] cur=8097c65c NSObject
The first line shows the object itself, the second the object's
class. The third the object's meta-class (class's class).
After that, you see the rooting of this particular hierarchy..
As others have suggested before: please learn something about the
language before making comments, especially comments containing
extremely irritating and emotive language like yours.
[more false conclusions snipped]
Marcel
--
Eilige Menschen haben kein Glueck.
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
jcr> Your insistence on the narrowest possible definition of
jcr> "message-sending" is not a "revelation", but simply a case
jcr> of posturing. You are not "the bearer of bad tidings", you
jcr> are merely someone who is very verbose in stating your
jcr> unfounded opinions.
Curiously enough, not only GNU Objective C (as illustrated in another
article) ``believes'' the same bizrre opinions, but Brad Cox expressed
much the same unfounded opinions in some of his papers (and the ancient
News article I have quoted in another article), because he was very well
aware that message passing and function call semantics are very
different; I guess that he quite consciously chose function call
semantics for Objective C ``message passing'' because of the performance
implications, as well as consistency with C.
For example, consider a paper in which he discusses what are actually
actor style high level frameworks contrasted to the subroutine semantics
of Objective-C ``messaging'':
http://WWW.VirtualSchool.edu/cox/CoxTaskMaster.html
"Example: TaskMaster and Objective-C
Stepstone's experience with Objective-C is a final example of why a
multilevel software architecture is desirable. Whereas Metaphor's
experience shows that skilled programmers need lower-level
architectural standards than Metaphor's card-level objects,
Stepstone's experience shows that users need higher-level kinds of
objects than the textual, synchronous objects of Objective-C;
objects that communicate by sending each other messages where the
receiver computes as a subroutine of the sender, rather than as a
coroutine.
The key concepts that distinguish higher-level user-programmable
systems from the specialized programming languages of today, of
which Objective-C is a typical example, are an iconic user
interfaces (instead of a textual programming language) and
concurrent (asynchronous, non-procedural) objects that operate as
coroutines of one another, not subroutines."
and in the article I have quoted elsewhere:
Erik M. Buck
> >>> On Sat, 21 Apr 2001 11:24:15 -0500, "Erik M. Buck"
> >>> <buck...@mcleodusa.net> said:
>
> buck.erik> It is not possible in Objective-C to know in all cases what
> buck.erik> object in what process space on what machine will received
> buck.erik> the message "selector" in the following expression: [receiver
> buck.erik> selector]; Since the programmer can not always know, the
> buck.erik> programmer has to assume the most general semantic. The most
> buck.erik> general semantic is message passing.
>
> If this bit of weird imagination had any relationship to what Objective
> C is about, then the use of the NeXTStep extensions 'in', 'out',
> ... would be mandatory for the relevant argument types, because without
> those it is well quite hard :-> to maintain appropriate semantics in
> both the same address space and the distributed case.
>
> However the reality is that these type modifiers are not used
> universally, but precisely only for those methods that are expected to
> be invoked via DO/GNUStep.
>
You agree that in the distributed objects case "real" message passing is
happening.
Since the programmer can not necessarily tell if an anonymous object is
local or remote then the programmer must assume the most general case of
"real" message passing.
buck.erik> The object that sends the message "selector" need not block
buck.erik> nor wait for any return value. The sender object can proceed
buck.erik> asynchronously.
Since the programmer does not know if the receiver of a message is local or
remote and the above statement is true in the remote case then the
programmer must assume the above statement may be true in the general case.
buck.erik> The message may not even be delivered to any object. If
buck.erik> "receiver" happens to be in the same process space as the
buck.erik> sender then a fast synchronous optimization is applied.
You showed in you post that oneway does have meaning in the distributed case
and that it is ignored in the local case. You seem to agree with everything
I have stated. You provided an example where all objects were local and the
optimization was applied for all "messages". If you build an example where
all objects are distributed you will see the exact opposite: none of the
messages will be optimized into the "fast synchronous" form of dispatching
that looks a lot like a function call.
You seem to be claiming that since Objective-C optimizes the most common
case in which the sender and receiver of a message are in the same process
space that Objective-C does not send messages. In all cases the semantic is
message sending. In the distributed case the message is sent like it would
be in "actor" languages and keywords like oneway have meaning. In the local
case the same semantic is preserved, but the message send operation is
optimized and the oneway keyword is ignored.
So what is your objection and how to you get away with claiming that
Objective-C does not support message passing ?
Argue how many angels fit on the head of a pin next.
Piercarlo Grandi
>>> said:
[ ... ]
pg> Never mind that one of the fundamental design decisions of Objective
pg> C (like some versions of Smalltalk before Smalltalk-80) was _not_ to
pg> have a metaclass system and _not_ to materialize classes as class
pg> objects!
marcel> Wrong. Although class-objects are created statically,
marcel> they are actual objects with an isa-pointer pointing to a
marcel> meta-class object.
You are confusing (with quite a bit of imagination) the layout of
internal runtime datastructures (which includes the 'isa' pointer) with
a class object or a metaclass, which are _language_ level entities (and
the 'isa' pointer is not).
It is possible to declare or instantiate a class in Objective C, and to
do a full set of operations on class instances, but there is no way, by
design, to declare or instantiate a metaclass (or a metaclass object),
or to operate on a (non existent) metaclass instance, as anybody who has
read the language manuals, even the GNU Objective C or the NeXT/Apple
ones, surely realizes.
To reflect at runtime on class properties one does not access non
existent metaclass objects, one uses framework/runtime dependent
facilities, e.g.:
The existence of such facilities is indeed required, as there are no
class or metaclass objects; if these existed, there would be no need for
such framework/runtime facilities.
However I understand that, as usual, I shall have to explain everything
from first principles...
Let's look again at the example that is alleged to demonstrate the
existence of metaclasses and their instances in Objective C:
------------------------------------------------------------------------
$ cat metaClass.m
#import <Foundation/Foundation.h>
main()
{
id obj=@"Hello World";
id *cur=(id*)obj;
int i;
for (i=0;i<10;i++) {
NSLog(@"cur=%x %@",cur,cur);
cur=*cur;
}
}
$ gcc -Wno-import -o metaClass metaClass.m -lobjc -lptrheads
metaClass.m:1: Foundation/Foundation.h: No such file or directory
------------------------------------------------------------------------
It fails even to compile. Note that I have a full Objective C compiler
that someone has claimed is used by 99.9% of Objective C programmers,
and it is pretty much guaranteed that it can compile the full language
and quite a few extensions.
So how comes that the example ```works'' for you, but not for me?
Simply because the example above is, quite disingenuously, testing _not_
the properties of the Objective C language, nor even of the GNU
Objective C language, but those of a particular implementation of a
specific framework, that does provide in some specific way some
intelligently arranged layout of metadata and some reflective abilities.
Even worse, it is, again quite disingenuously, an erroneously
meaningless Objective C program, presented as if it were valid; it
is erroneous because in:
------------------------------------------------------------------------
id obj=@"Hello World";
id *cur=(id*)obj;
[ ... ]
cur=*cur;
------------------------------------------------------------------------
the cast from 'id' to 'id *' is meaningless in the second line, and it
is also meaningless to assign an 'id' to an 'id *' in the last
line.
These invalid constructs do not result in syntax errors because the
_representation_ of 'id' is probably defined in that particular
implementation as the C type 'void *', which allows almost any amount of
type punning, even if the semantics are undefined and erroneous.
Whatever effect you achieve via those erroneous expressions not only
depends on framework dependent features, it relies on these
implementation dependent, not language dependent, features:
* an 'id' is actually a pointer-sized word;
* the first word of a class instance is a pointer to the 'struct' that
the compiler generates to allow reflection at runtime on some
properties of a class.
These are not properties of Objective C, they are accidents of
a particular runtime implementation; it is easy to imagine
implementations of Objective C in which neither property holds.
If you had wanted to demonstrate that some implementations of Objective
C do have runtime systems that do offer reflection using things that are
designed to _look like at runtime_ metaclasses and their instances, you
should have at least produced a competently written reflective program,
for example, by using the GNU Objective C reflection abilities, as it
has some.
In the interest of demonstrating how [GNU] Objective C reflection
actually works, and that it is very different from having a metaclass
system like Smalltalk-80 or Python, I have written an example that is
not as laughably disingenuous as yours.
Naturally, as the comments below say, this is not a demonstration of the
existence of the mythical metaclasses or class objects of Objective C,
it is just an implementation dependent demonstration of how one can take
advantage of the reflective abilities provided in one particular
Objective C implementation, and documented in '<objc/objc.h>' and
'<objc/Object.h>':
------------------------------------------------------------------------
$ cat metaClass.m
#include <stdio.h>
#include <objc/objc.h>
#include <objc/Object.h>
@interface Base: Object
{ const char *n; }
+ new;
- (const char *) name;
@end
@implementation Base
+ new { return [super new]; }
- (void) name: (const char *) name { n = name; }
- (const char *) name { return n; }
@end
@interface Derived: Base @end
@implementation Derived @end
@interface Leaf: Derived @end
@implementation Leaf @end
enum Kind { noKind, anInstance, aClass, aMetaClass };
void printReflective(const id o,const unsigned level)
{
const Class c = [o class];
const Class s = [o superClass];
const char *const n = [o name];
/*
The casts below unfortunately are illegal (there is no legal way
in GNU Objective C to access reflective information directly as
Objective C objects), as we are casting a pointer to a C level 'struct
objc_class' into an 'id', which can only denote Objective C objects;
but 'struct objc_class' in the GNU Objective C '<objc/objc.h>'
headers has been laid out carefully so that things actually work to
some extent.
*/
const char *const n_c = [((id) c) name];
const char *const n_s = [((id) s) name];
const enum Kind k =
([o isInstance]) ? anInstance
: ([o isClass]) ? aClass
: ([o isMetaClass]) ? aMetaClass
: noKind;
{
int j;
for (j = 0; j <= level; j++) putchar(' ');
}
switch (k)
{
case anInstance:
printf("instance %#08x '%s': class %#08x '%s' super %#08x '%s'\n",
(unsigned) (void *) o,n,
(unsigned) (void *) c,n_c,
(unsigned) (void *) s,n_s);
break;
case aClass:
{
const MetaClass m = [o metaClass];
const char *const n_m = [((id) m) name];
printf("``class'' %#08x '%s': class %#08x '%s' super %#08x '%s' meta %#08x '%s'\n",
(unsigned) (void *) o,n,
(unsigned) (void *) c,n_c,
(unsigned) (void *) s,n_s,
(unsigned) (void *) m,n_m);
}
break;
case aMetaClass:
{
const MetaClass m = [o metaClass];
const char *const n_m = [((id) m) name];
printf("``meta'' %#08x '%s': class %#08x '%s' super %#08x '%s' meta %#08x '%s'\n",
(unsigned) (void *) o,n,
(unsigned) (void *) c,n_c,
(unsigned) (void *) s,n_s,
(unsigned) (void *) m,n_m);
}
break;
default:
printf("? '%s': address %#08x\n",n,(unsigned) o);
break;
}
}
int main(int argc,char **argv)
{
unsigned i;
id o = [Leaf new];
[o name: "o"];
{
id p;
fputs("Inheritance hierarchy\n",stdout);
for (p = o, i = 0; i < 4; i++)
{
printReflective(p,i);
p = (id) (void *) [p superClass];
}
fputs("``metaclass'' hierarchy\n",stdout);
for (p = o, i = 0; i < 3; i++)
{
printReflective(p,i);
p = (id) (void *) [p class];
}
}
}
$ gcc -ggdb -o metaClass metaClass.m -lobjc -lpthread
$ ./metaClass
Inheritance hierarchy
instance 0x8057000 'o': class 0x8054460 'Leaf' super 0x80544e0 'Derived'
``class'' 0x80544e0 'Derived': class 0x80544e0 'Derived' super 0x80545a0 'Base' meta 0x80544a0 'Derived'
``class'' 0x80545a0 'Base': class 0x80545a0 'Base' super 0x8054aa0 'Object' meta 0x8054560 'Base'
``class'' 0x8054aa0 'Object': class 0x8054aa0 'Object' super 00000000 '(null)' meta 0x8054a60 'Object'
``metaclass'' hierarchy
instance 0x8057000 'o': class 0x8054460 'Leaf' super 0x80544e0 'Derived'
``class'' 0x8054460 'Leaf': class 0x8054460 'Leaf' super 0x80544e0 'Derived' meta 0x8054420 'Leaf'
``class'' 0x8054460 'Leaf': class 0x8054460 'Leaf' super 0x80544e0 'Derived' meta 0x8054420 'Leaf'
------------------------------------------------------------------------
I guess that this is abundantly clear; In this particular implementation
the runtime table have been carefully manually arranged to look as if
they were objects (in '<objc/objc.h>'), and by doing a bit of type
punning between the type of those tables and an objective C type one can
see that there is a superclass chain, and this is reasonable, but the
metaclass chain is a bit peculiar (a class is its own ``metaclass'', or
more precisely, there are no metaclasses).
Note also that while this program is not a silly joke like yours, it is
still an implementation dependent hack, and not a demonstration of the
existence of hallucinations like metaclasses and their instances in
Objective C; it is also clear that the ``metaclass'' hierarchy, or
rather the runtime data generated by the compiler, have a _different_
shape in GNU Objective C than in the implementation you have been using,
which again shows that reflection is done differently in different
implementations.
While your example does not support the hallucination that in Objective
C, the language, there are metaclasses and their instances, it
demonstrates that:
* The author does not understand the distinction between valid and
undefined language semantics.
* The author has no idea of the difference between a language and a
particular implementation of the language.
* The author cannot figure out what is a property of a specific
framework and a property of a language that uses that framework.
* The Cocoa framework (if this is what you are using) probably hacks its
runtime data in a different way from the GNU Objective C runtime; but
given that your Cocoa example is erroenous, even this is not that clear.
Let's double check; there is something that is allegedly the reference
manual for Cocoa's Objective C:
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/AppendixB/
There is no mention anywhere in the language defition of metaclasses or
class objects; they are entities that simply do not exist in the
language, like closures/continuations, message sending, distributed
objects, threads or a million other concepts that can (and are
sometimes) provided by the runtime system, but are built in to other
languages that have been designed differently.
Admittedly a lot of people will have been confused by poorly written
introductory and explanatory material that mentions fantasies like
message sending or metaclasses in C; for example the Objective C
introduction at:
http://developer.Apple.com/techpubs/macosx/Cocoa/ObjectiveC/3CoreObjC/
contains, among a number of entirely comical howlers (e.g. the "Static
typing" section in "Classes.html"), the following amusing statement:
------------------------------------------------------------------------
The 'isa' pointer also enables objects to introspect about themselves as
objects. The compiler doesn't discard much of the information it finds
in source code; it arranges most of it in data structures for the
run-time system to use. Through 'isa', objects can find this information
and reveal it at run time.
------------------------------------------------------------------------
which may have given people the impression that 'isa', and the ``class
object'' it points to are properties of the language, which it is not
(in GNU Objective C this is just the 'class_pointer' field of the
'struct objc_class' in the runtime system).
So, while metaclass and class objects can and do support reflection, in
languages that do have them, the presence of reflection does not imply
the existence of metaclass and their classes.
BTW, I once had a long and similar discussion with some Smalltalk-80
programmers that had a slightly fantasy: that classes and class
objects are the same thing...
Consider the difference between Python and Java: Java, like Objective C
and C++, does not have any metclass system or class objects; but like
Objective C it does support reflection, that allows one to interrogate
and list the properties of classes and other language entities, by using
runtime library facilities.
Part of the reason why Objective-C was designed without a metaclass
system is that it is very hard to design one, and it is not that useful,
and one can get much the same benefits by just exposing some entry
points in the runtime system for reflection.
Piercarlo Grandi
>>> <buck...@mcleodusa.net> said:
[ ... ]
buck.erik> You showed in you post that oneway does have meaning in the
buck.erik> distributed case and that it is ignored in the local case.
This paraphrase dishonestly omits the vital point that I showed that
'oneway' has meaning in _GNUStep_, but no meaning in _GNU Objective C_,
and that we are arguing about the semantics of Objective C, not of
GNUStep.
Your hallucinatory claims were all about GNU Objective C, not about
GNUStep:
buck.erik> [ ... ] It is not possible in Objective-C to know in all
buck.erik> cases what object in what process space on what machine
buck.erik> will received the message "selector" in the following
buck.erik> expression: [receiver selector]; Since the programmer can
buck.erik> not always know, the programmer has to assume the most
buck.erik> general semantic. The most general semantic is message
buck.erik> passing. [ ... ] Both Gnu Objective-C and Apple/NeXT
buck.erik> Objective-C work in exactly this way. [ ... ]
and in that article you have not mentioned GNUStep or other distributed
objects framework built on top or alongside it.
Somewhow it does not surprise me that once your fantasies about the
semantics of GNU Objective C have been proven to be baseless you produce
arguments that carefully avoid mentioning the difference between the
language and one of its frameworks.
buck.erik> You seem to agree with everything I have stated.
This seems to me a misrepresentation of my argument; you have made
blatantly incorrect claims about GNU Objective C, that I have proven to
be entirely false.
buck.erik> You provided an example where all objects were local and the
buck.erik> optimization was applied for all "messages".
This looks to me a malicious paraphrase of my example: it is an example
of a program written in [GNU] Objective C, and in GNU Objective C there
is no special case where objects are local and another special case
where objects can be distributed; there is no such distinction.
Objects can be transparently local or distributed as long as the
language semantics, which are applicative, are maintained.
GNUStep instead is a different matter, in which one can choose between
simulated applicative and non applicative semantics. GNUStep, or Cocoa,
are not part of Objective C; they are distinct projects that, in the
case of Cocoa, are actually multiple languages, and they have their own
semantics distinct from those of the languages they support, just like
CORBA, for example.
[ ... ]
buck.erik> You seem to be claiming that since Objective-C optimizes the
buck.erik> most common case in which the sender and receiver of a
buck.erik> message are in the same process space that Objective-C does
buck.erik> not send messages.
This seems to me a dishonest paraphrase of my argument; my argument,
which I have made clear many times, and you still try to twist it into
something else, is that Objective C is based on applicative semantics,
and GNU Objective C accordingly only supports applicative semantics, and
that these must be maintained whether function calling is local or
remote.
In the local case, applicative semantics can be implemented directly; in
the remote case, they can only be maintained by using a message passing
substrate, which is not part of the language itself.
Also, the presence of the 'oneway' qualifier in one particular
implementation of Objective C is relevant only to some particular
frameworks that are not Objective C and have different semantics from
that language.
buck.erik> In all cases the semantic is message sending.
In all case the semantic, for Objective C, is applicative; let's look
again, just for illustrative purposes, using an implementation as an
example, e.g. the freely available GNUStep.
Consider this in 'Source/callframe.m', which implements RPC argument
passing:
------------------------------------------------------------------------
if (out_parameters || *tmptype != _C_VOID || (flags & _F_ONEWAY) == 0)
/* xxx What happens with method declared "- (oneway) foo: (out int*)ip;" */
/* xxx What happens with method declared "- (in char *) bar;" */
/* xxx Is this right? Do we also have to check _F_ONEWAY? */
------------------------------------------------------------------------
The questions above don't make sense unless RPCs are expected to have
applicative semantics and there is difficulty in [un]mapping them across
the message passing substrate that GNUStep must use.
Also, consider a few other comments in the same source, which is the bit
in the framework that simulates (as much as possible) the natural
Objective C applicative semantics given the underlying messaging
transport:
------------------------------------------------------------------------
/* callframe_do_call()
This function decodes the arguments of method call, builds an
argframe of type arglist_t, and invokes the method using
__builtin_apply; then it encodes the return value and any
pass-by-reference arguments.
------------------------------------------------------------------------
------------------------------------------------------------------------
/* Return the number of arguments that the method MTH expects. Note
that all methods need two implicit arguments `self' and `_cmd'.
From mframe.m */
------------------------------------------------------------------------
------------------------------------------------------------------------
/* If the pointer's value is qualified as an OUT parameter,
or if it not explicitly qualified as an IN parameter,
then we will have to get the value pointed to again after
the method is run, because the method may have changed
it. Set OUT_PARAMETERS accordingly. */
------------------------------------------------------------------------
------------------------------------------------------------------------
/* Handle an argument that is a pointer to a non-char. But
(void*) and (anything**) is not allowed. */
------------------------------------------------------------------------
The comments make it clear that even GNUStep is not trying to optimise
message passing semantics into a function call implementation; it is
doing quite the opposite, trying pretty hard to simulate function
calling and argument passing by encoding a function call stack frame to
a message, shipping it around, and recreating it on the target machine.
In particular the bit where it says that "we will have to get the value
pointed to again after the method is run, because the method may have
changed it." makes it very clear that it is trying hard to simulate
ordinary ``by reference'' shared memory semantics, by implicitly turning
it into copy-in/copy-out (close but not quite) semantics.
This would make no sense if the semantics of the original method call
were to be assumed to be message passing:
buck.erik> [ ... ] Since the programmer can not always know, the
buck.erik> programmer has to assume the most general semantic. The
buck.erik> most general semantic is message passing. [ ... ]
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Mon, 23 Apr 2001 11:40:52 -0500, "Erik M. Buck"
> >>> <buck...@mcleodusa.net> said:
>
> [ ... ]
>
> buck.erik> You showed in you post that oneway does have meaning in the
> buck.erik> distributed case and that it is ignored in the local case.
>
> This paraphrase dishonestly omits the vital point that I showed that
> 'oneway' has meaning in _GNUStep_, but no meaning in _GNU Objective C_,
> and that we are arguing about the semantics of Objective C, not of
> GNUStep.
What in the world are you talking about? in, out, inout, and oneway are
*keywords* in GNU Obj-C. Of *course* they have meaning in Obj-C.
-jcr
John C. Randolph
This quote in no way supports your contention that Obj-C doesn't perform
message-passing. Show me any place where Cox said that message passing
isn't message passing if it takes place withing a single thread of control.
> and in the article I have quoted elsewhere:
>
> From: c...@stpstn.UUCP (Brad Cox)
> Subject: Re: Message-Passing and Generative Communication
> Date: 28 Apr 90 17:23:40 GMT
>
> "But as you point out, such objects are still *passive*, in that
> they lie there as limply as conventional data variables until the
> outside world passes them a thread of control, which they share as
> subroutines, rather than as coroutines."
Again, this quote also fails to support your position. So Cox says that
objects have to wait for a thread of control. So what?
I could just as well claim that no higher-level semantics exist at all,
since it all comes down to NAND gates in the end.
-jcr
Marcel Weiher
>pg> Never mind that one of the fundamental design decisions of Objective
>pg> C (like some versions of Smalltalk before Smalltalk-80) was _not_ to
>pg> have a metaclass system and _not_ to materialize classes as class
>pg> objects!
>marcel> Wrong. Although class-objects are created statically,
>marcel> they are actual objects with an isa-pointer pointing to a
>marcel> meta-class object.
>You are confusing (with quite a bit of imagination) the layout of
No, *you* are confusing things. I implemented an Objective-C system
more than a decade ago. Now, learn something or shut up.
>internal runtime datastructures (which includes the 'isa' pointer) with
>a class object or a metaclass, which are _language_ level entities (and
>the 'isa' pointer is not).
Wether an object is instantiated by the runtime or created
statically is of no concern to the rest of the runtime.
Message lookup proceeds identically, and there is no other
definition of 'object' in the language other than 'something
that responds to messages' as sent via the runtime.
>It is possible to declare or instantiate a class in Objective C, and to
>do a full set of operations on class instances, but there is no way, by
>design, to declare or instantiate a metaclass (or a metaclass object),
You are quite mistaken. The meta-class is defines using C-structures,
and C just happens to be part of Objective-C. I repeat myself: learn
something about the language before making more of a fool out o \yourself.
>or to operate on a (non existent) metaclass instance, as anybody who has
>read the language manuals, even the GNU Objective C or the NeXT/Apple
>ones, surely realizes.
You might want to talk to people who have actually implemented
Objective-C compilers and not just read the manuals. You
might learn something. Or you can continue to spout
hot air.
>To reflect at runtime on class properties one does not access non
>existent metaclass objects, one uses framework/runtime dependent
>facilities, e.g.:
The meta-class objects exist and respond to messages. However,
they aren't used for much except keeping class-messages.
>The existence of such facilities is indeed required, as there are no
>class or metaclass objects; if these existed, there would be no need for
>such framework/runtime facilities.
False again. The meta-class-objects are required in order to be able
to use the (exact) same mechanism to send messages to classes that
is used to send messages to objects. But you wouldn't know about
that.
>However I understand that, as usual, I shall have to explain everything
>from first principles...
You don't have to explain anything about Objective-C to anyone here.
As I said before: learn about the language, then post. You'd
make less of a fool out of yourself. And can the attitude.
>It fails even to compile. Note that I have a full Objective C compiler
>that someone has claimed is used by 99.9% of Objective C programmers,
>and it is pretty much guaranteed that it can compile the full language
>and quite a few extensions.
If you'd actually know something about the language, you'd know
that this isn't a compiler/language issue but a framework issue.
You'd also know how to (trivially) modify the example to work
with a different framework. Extra-credit question: why did
I not choose are root object (such as NSObject or Object), but
rather a class a little further down the inheritance chain?
>So how comes that the example ```works'' for you, but not for me?
Because I have a Foundation and you don't? Duh.
>Simply because the example above is, quite disingenuously, testing _not_
>the properties of the Objective C language, nor even of the GNU
>Objective C language, but those of a particular implementation of a
>specific framework, that does provide in some specific way some
>intelligently arranged layout of metadata and some reflective abilities.
If you actually knew something about the language, which you
obviously don't, you'd know that this test actually tests the
runtime layout shared by all implementations, the one that
is outlined in Brad Cox's book. Of course, you don't actually
know anything about the language.
>Even worse, it is, again quite disingenuously, an erroneously
>meaningless Objective C program, presented as if it were valid; it
>is erroneous because in:
Once again, if you'd actually know something about the language,
you'd know what a bunch of BS that is.
I will repeat this: C is a part of Objective-C.
Try to think about that.
>------------------------------------------------------------------------
> id obj=@"Hello World";
> id *cur=(id*)obj;
> [ ... ]
> cur=*cur;
>------------------------------------------------------------------------
>the cast from 'id' to 'id *' is meaningless in the second line, and it
>is also meaningless to assign an 'id' to an 'id *' in the last
>line.
You just betray more of your ignorance. Oh well, suit yourself.
>These invalid constructs do not result in syntax errors because the
They are quite valid, though I could have chosen something
different.
>_representation_ of 'id' is probably defined in that particular
>implementation as the C type 'void *', which allows almost any amount of
>type punning, even if the semantics are undefined and erroneous.
You are wrong again.
>Whatever effect you achieve via those erroneous expressions not only
>depends on framework dependent features, it relies on these
Wrong: it relies on the runtime.
>implementation dependent, not language dependent, features:
Objective-C is largely defined by its runtime.
>* an 'id' is actually a pointer-sized word;
Though not entirely incorrect, this is incomplete:
typedef struct objc_object {
Class isa;
} *id;
So, what I should have done is
id obj;
[..]
obj=obj->isa;
Same difference, though.
>* the first word of a class instance is a pointer to the 'struct' that
> the compiler generates to allow reflection at runtime on some
> properties of a class.
It is an isa pointer that points to another class:
struct objc_class {
struct objc_class *isa;
struct objc_class *super_class;
...
}
But I wouldn't expect you to know that.
>These are not properties of Objective C, they are accidents of
>a particular runtime implementation;
Objective-C is defined by its runtime.
>it is easy to imagine
>implementations of Objective C in which neither property holds.
It is easy to engage in "wild fantasies" where this is true. However,
such imaginary languages do not exist.
[rest, including laughable example snipped]
Marcel Weiher
>This paraphrase dishonestly omits the vital point that I showed that
>'oneway' has meaning in _GNUStep_, but no meaning in _GNU Objective C_,
>and that we are arguing about the semantics of Objective C, not of
>GNUStep.
Wrong. 'oneway' is defined by the language.
[more idiocies snipped]
Marcel Weiher
>Piercarlo Grandi wrote:
[quoting Brad Cox]
>> Stepstone's experience with Objective-C is a final example of why a
>> multilevel software architecture is desirable. Whereas Metaphor's
>> experience shows that skilled programmers need lower-level
>> architectural standards than Metaphor's card-level objects,
>> Stepstone's experience shows that users need higher-level kinds of
>> objects than the textual, synchronous objects of Objective-C;
>> objects that communicate by sending each other messages where the
>> receiver computes as a subroutine of the sender, rather than as a
>> coroutine.
[..]
>This quote in no way supports your contention that Obj-C doesn't perform
>message-passing. Show me any place where Cox said that message passing
>isn't message passing if it takes place withing a single thread of control.
Yes, it's even the opposite. The above quote seems to quite clearly
distinguish two different kinds of message passing.
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On 23 Apr 2001 13:24:45 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
> >>> said:
>
> [ ... ]
>
> pg> Never mind that one of the fundamental design decisions of Objective
> pg> C (like some versions of Smalltalk before Smalltalk-80) was _not_ to
> pg> have a metaclass system and _not_ to materialize classes as class
> pg> objects!
>
> marcel> Wrong. Although class-objects are created statically,
> marcel> they are actual objects with an isa-pointer pointing to a
> marcel> meta-class object.
>
> You are confusing (with quite a bit of imagination) the layout of
> internal runtime datastructures (which includes the 'isa' pointer) with
> a class object or a metaclass, which are _language_ level entities (and
> the 'isa' pointer is not).
Marcel is not "confusing" the runtime data structures, he is using them
to show you what objects belong to what class. Obj-C binds objects to
their classes through the isa pointer.
[snippage]
> The existence of such facilities is indeed required, as there are no
> class or metaclass objects; if these existed, there would be no need for
> such framework/runtime facilities.
There are both class and metaclass objects in Objective-C. Your
pedantic insistence to the contrary doesn't make them go away.
> However I understand that, as usual, I shall have to explain everything
> from first principles...
..which you'll make up on the fly, I'm sure.
> Let's look again at the example that is alleged to demonstrate the
> existence of metaclasses and their instances in Objective C:
>
> ------------------------------------------------------------------------
> $ cat metaClass.m
> #import <Foundation/Foundation.h>
>
> main()
> {
> id obj=@"Hello World";
> id *cur=(id*)obj;
> int i;
> for (i=0;i<10;i++) {
> NSLog(@"cur=%x %@",cur,cur);
> cur=*cur;
> }
> }
> $ gcc -Wno-import -o metaClass metaClass.m -lobjc -lptrheads
> metaClass.m:1: Foundation/Foundation.h: No such file or directory
> ------------------------------------------------------------------------
>
> It fails even to compile.
It compiles just fine. You have to be smart enough to tell it where to
look for the header and the foundation framework.
> Note that I have a full Objective C compiler
> that someone has claimed is used by 99.9% of Objective C programmers,
> and it is pretty much guaranteed that it can compile the full language
> and quite a few extensions.
>
> So how comes that the example ```works'' for you, but not for me?
Apparently because you're incapable of using the CC command-line option
that advises the compiler of where to look for header files. Hint: "-I".
> Simply because the example above is, quite disingenuously, testing _not_
> the properties of the Objective C language, nor even of the GNU
> Objective C language, but those of a particular implementation of a
> specific framework, that does provide in some specific way some
> intelligently arranged layout of metadata and some reflective abilities.
Umm, no. The only thing he used that required a specific framework was
the NSLog() function.
> Even worse, it is, again quite disingenuously, an erroneously
> meaningless Objective C program, presented as if it were valid; it
> is erroneous because in:
>
> ------------------------------------------------------------------------
> id obj=@"Hello World";
> id *cur=(id*)obj;
> [ ... ]
> cur=*cur;
> ------------------------------------------------------------------------
>
> the cast from 'id' to 'id *' is meaningless in the second line, and it
> is also meaningless to assign an 'id' to an 'id *' in the last
> line.
>
> These invalid constructs do not result in syntax errors because the
> _representation_ of 'id' is probably defined in that particular
> implementation as the C type 'void *', which allows almost any amount of
> type punning, even if the semantics are undefined and erroneous.
The type conversion has nothing to do with his point. The significance
is in what you get when you follow those pointers, i.e., the classes and
the metaclass.
[the rest of Grandi's longwinded, irrelevant dissertation snipped.]
-jcr
Piercarlo Grandi
marcel> pg...@sabi.Clara.co.UK (Piercarlo Grandi) writes:
>> This paraphrase dishonestly omits the vital point that I showed that
>> 'oneway' has meaning in _GNUStep_, but no meaning in _GNU Objective
>> C_, and that we are arguing about the semantics of Objective C, not
>> of GNUStep.
marcel> Wrong. 'oneway' is defined by the language.
This is narrowly true, and dishonestly misleading; as I have stated, and
you have conveniently omitted, GNU Objective C supports the _syntax_ of
the 'oneway' type qualifier, but does not support its _semantics_, as I
have clearly proved.
Only GNUStep, which is not GNU Objective C, actually implements _any_
semantics for the keyword, as anybody knows, if they have the least
familiarity with GNU Objective C and GNUStep, or has the intellectual
bandwidth to understand the GNU Objective C and GNUStep sources.
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On 23 Apr 2001 21:50:26 GMT, mar...@cs.tu-berlin.de (Marcel Weiher) said:
>
> marcel> pg...@sabi.Clara.co.UK (Piercarlo Grandi) writes:
>
> >> This paraphrase dishonestly omits the vital point that I showed that
> >> 'oneway' has meaning in _GNUStep_, but no meaning in _GNU Objective
> >> C_, and that we are arguing about the semantics of Objective C, not
> >> of GNUStep.
>
> marcel> Wrong. 'oneway' is defined by the language.
>
> This is narrowly true, and dishonestly misleading; as I have stated, and
> you have conveniently omitted, GNU Objective C supports the _syntax_ of
> the 'oneway' type qualifier, but does not support its _semantics_, as I
> have clearly proved.
All that you've proven is that you have an amazing ability to ignoer
examples placed in front of you. I've shown you that Obj-c performs
message passing (even fitting your absurdly narrow definition of the
moment), and Marcel has shown you that Obj-C classes are members of a metaclass.
> Only GNUStep, which is not GNU Objective C, actually implements _any_
> semantics for the keyword, as anybody knows, if they have the least
> familiarity with GNU Objective C and GNUStep, or has the intellectual
> bandwidth to understand the GNU Objective C and GNUStep sources.
Do you have the intellectual bandwidth to grasp that you're making a
fool of yourself by ignoring examples of things that you say Obj-C
doesn't have or can't do?
FYI, the NeXT/Apple Distributed Objects system does indeed implement "oneway".
-jcr
Marcel Weiher
>marcel> Wrong. 'oneway' is defined by the language.
>This is narrowly true, and dishonestly misleading;
No. It is true. Simply true. Deal with it.
>as I have stated, and
>you have conveniently omitted, GNU Objective C supports the _syntax_ of
>the 'oneway' type qualifier, but does not support its _semantics_, as I
>have clearly proved.
So you are drawing conclusions from one accidental implementation?
Tsk,Tsk, Tsk, shame on yo.
>Only GNUStep, which is not GNU Objective C, actually implements _any_
>semantics for the keyword,
Of course, this is complete bollocks, but I wouldn't expect you
to know this. You probably don't even begin to have an idea
on just how many levels this is bollocks, do you?
>as anybody knows, if they have the least
>familiarity with GNU Objective C and GNUStep, or has the intellectual
>bandwidth to understand the GNU Objective C and GNUStep sources.
ROTFLMAO!
This guy is almost as funny as David.
Marcel Weiher
>FYI, the NeXT/Apple Distributed Objects system does indeed implement "oneway".
And I might be tempted to do a HOM-implementation of oneway just for
laughs. Although this dude probably just wouldn't get it...
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
pg> You are confusing (with quite a bit of imagination) the layout of
pg> internal runtime datastructures (which includes the 'isa' pointer) with
pg> a class object or a metaclass, which are _language_ level entities (and
pg> the 'isa' pointer is not).
jcr> Marcel is not "confusing" the runtime data structures, he is
jcr> using them to show you what objects belong to what class.
jcr> Obj-C binds objects to their classes through the isa pointer.
But there is not such thing as the 'isa' pointer in Objective C: try to
find anywhere in the Cocoa Objective C reference manual, for example,
any mention of the 'isa' pointer. There is an 'isa' variable in the
implementation of class 'Object', but given that it is invisible to
programs it is not part of the language.
What binds objects to reflective metadata is not Objective C, it is its
_runtime system_. In the case of the GNU Objective C runtime system the
'isa' attribute is, correctly, part of the implementation, not the
language visible interface, of the special 'Object' class; in this class
one can find constructs like:
------------------------------------------------------------------------
- (BOOL)isKindOf:(Class)aClassObject
{
Class class;
for (class = self->isa; class!=Nil; class = class_get_super_class(class))
if (class==aClassObject)
return YES;
return NO;
}
------------------------------------------------------------------------
Note that, properly, no ``messaging'' is applied to 'Class' values
(which are not objects in the Objective C sense); only internal runtime
C functions like 'class_get_superclass()' are used.
If 'class' in the fragment of code above were indeed an Objective C
object, applying C functions to it would be illegal, because Objective C
objects cannot be accessed or manipulated via C functions, only via
the methods defined for their class.
Let me quote from a book ("Object oriented languages. that uses the
ridiculous ``message sending'' termonology, on this point, in a section
where Simula, Smalltalk, CLOS, C++, Objective-C and Eiffel (all pretty
old variants) are compared:
"Smalltalk and Objective-C distinguish between the scope of
_variables_, which can only be accessed from methods of the object
possessing the variable, and the scope of _methods_, which can
accessed from anywhere".
"Only Smalltalk and CLOS provide systematic metalevel facilities of
any kind. Each of the other languages is strongly isolated from its
own implementation, and it is not practical in these languages to
alter the interpretation of basic language statements, the inheritance
scheme, or the behaviour of classes."
That there is a vital distinction between a language and its
implementation is something that is taught in beginner compsci classes;
evidently some people sleep thru them...
pg> $ gcc -Wno-import -o metaClass metaClass.m -lobjc -lptrheads
pg> metaClass.m:1: Foundation/Foundation.h: No such file or directory
pg> It fails even to compile.
jcr> It compiles just fine. You have to be smart enough to tell
jcr> it where to look for the header and the foundation framework.
This point is based on ingoring that we are talking about the properties
of GNU Objective C, not about the properties of one of the frameworks
GNU Objective C programs can use.
pg> Note that I have a full Objective C compiler that someone has claimed
pg> is used by 99.9% of Objective C programmers, and it is pretty much
pg> guaranteed that it can compile the full language and quite a few
pg> extensions.
pg> So how comes that the example ```works'' for you, but not for me?
jcr> Apparently because you're incapable of using the CC command-line
jcr> option that advises the compiler of where to look for header files.
jcr> Hint: "-I".
This statement is based on the hallucination that that header is part of
GNU Objective C. In fact I don't have any file called 'Foundation.h'
anywhere on my computer, even if I do have the full GNU Objective C
installed; let's double check:
------------------------------------------------------------------------
$ tar tzf gcc-2.95.3.tar.gz | egrep Object.h
gcc-2.95.3/libobjc/objc/Object.h
$ tar tzf gcc-2.95.3.tar.gz | egrep Foundation.h
$ tar -tz -f gnustep-base-1.0.0.tar.gz | egrep Foundation.h
gnustep-base-1.0.0/Headers/gnustep/base/Foundation.h
$
------------------------------------------------------------------------
The lines above prove without doubt (unless one is in the habit of
letting one's fantasy run riot) that 'Foundation.h' is not a part of GNU
Objective C, and it happens instead to be part of the totally distinct
GNUStep library (and others, in different ways).
That header is not on my computer as I don't use GNUStep or any other
framework, because I write programs in pure [GNU] Objective C, which is
what we were discussing.
pg> Simply because the example above is, quite disingenuously, testing
pg> _not_ the properties of the Objective C language, nor even of the GNU
pg> Objective C language, but those of a particular implementation of a
pg> specific framework, that does provide in some specific way some
pg> intelligently arranged layout of metadata and some reflective
pg> abilities.
jcr> Umm, no. The only thing he used that required a specific
jcr> framework was the NSLog() function.
This is a blatant lie: the '<Foundation/Foundation.h>' header must be
part of _some_ framework library external to GNU Objective C, as it
surely is not part of GNU Objective C, as easily proved above.
Consider for example the following message in the _GNUStep_ mailing
list that mentions that header:
http://mail.gnu.org/pipermail/discuss-gnustep/1998-December/006857.html
"The other is related to the fact that for the majority of this code,
we simply do an #import <Foundation/Foundation.h> rather than import
each specific header individually. Because of this I noticed that
there are a lot of headers that are imported in OpenStep4.2's
Foundation.h that are not in GNUsteps Foundation.h (or included in
headers that are included in Foundation.h - as determined by
grepping)"
Note that, correctly, it is stated that the '<Foundation/Foundation.h>'
header is a feature of a couple of frameworks distinct from Objective C
the language; not only this, but the two frameworks implement the same
header with different semantics, as they can well do.
There is but one (at a time) GNU Objective C; there can be many
libraries that have a <Foundation/Foundation.h> header.
pg> Even worse, it is, again quite disingenuously, an erroneously
pg> meaningless Objective C program, presented as if it were valid; it is
pg> erroneous because in:
pg>
pg> ------------------------------------------------------------------------
id obj=@"Hello World";
id *cur=(id*)obj;
[ ... ]
cur=*cur;
pg> ------------------------------------------------------------------------
pg>
pg> the cast from 'id' to 'id *' is meaningless in the second line, and it
pg> is also meaningless to assign an 'id' to an 'id *' in the last
pg> line.
jcr> The type conversion has nothing to do with his point. The
jcr> significance is in what you get when you follow those pointers,
jcr> i.e., the classes and the metaclass.
But those pointers are part of the runtime/framework system, not of the
language, and his point was that [GNU] Objective C has got class objects
and metaclasses, not its runtime system; again, the idea that the
properties of the runtime/framework libraries are part of the properties
of the language only in ignorant fantasies.
There is no mention whatsoever of those pointers in the language
reference manual, and indeed in order to access those pointers one has
to violate the rules of the language.
Also, one does not get class objects and metaclasses by following those
pointers; one gets more or less random data structures that describe
program metadata, and, at least in GNU Objective C, no metaclasses even
if one squints their eyes pretty hard (it looks like the result of
'[aClass metaclass]' is a pointer to the class descriptor itself, in GNU
Objective C at least).
Note that I have stated several times that Objective C implementations
do have runtime/framework reflective metadata, that do describe class
attributes; but the ignorant fantasy I am objecting to is that class
objects and metaclasses are part of the GNU Objective C language,
something which is very distinct from its runtime or any framework that
can be used from it.
Similarly it would be fantasy to claim that GNU Objective C does have
threads; these are readily available from various libraries (e.g. the
NeXT/Apple ones), but those libraries are not part of the language, and
not even of the runtime libraries for the implementation of the language.
Also, those pointers to internal data structures can well be totally
differently implemented in different implementations of the language
(precisely because they are not part of the language specification).
Even more absurdly, using your inane reasoning one could write:
------------------------------------------------------------------------
id obj=@"Hello World";
int *cur=(id*)obj;
[ ... ]
printf("the superclass is an integer: %d\n",**cur);
------------------------------------------------------------------------
and prove that the superclass of 'obj' is an integer. It is in one
sense ``true'': it is represented as integers...
If a program is erroneous because of illicit type punning, no conclusion
can be drawn from it, except by people too ignorant to understand what a
language specification is and what a correct program in that language is.
Piercarlo Grandi
>>> said:
[ ... ]
marcel> Objective-C is largely defined by its runtime.
This is a masterpiece of kookdom: it is a statement that at the same
time demonstrates ignorance of what a language is, how Objective C is
actually defined, lack of a computer science education, arrogance,
buffoonery, disrespect for the audience, and utter dishonesty.
The statement above is not in fact just stupid: it is a shameless,
obvious, lie.
The lie that it is "largely defined by its runtime" looks like just a
desperate attempt to justify your previous, laughably incompetent
arguments in which you confused the language and the runtime.
It is a fact that Objective C, the original base language, was rather
well defined not by a runtime system but by a book, and that its
contemporary dialects are defined by other manuals; some obvious
ponters:
* Brad Cox, "Object-Oriented Programming: An Evolutionary Approach",
* Addison-Wesley, 1986.
* The StepStone Corporation, "The Objective-C Reference Manual", Sandy
Hook, CT, 1990.
* http://developer.Apple.com/techpubs/macosx/Cocoa/ObjectiveC/AppendixB/
As obvious proof that there are people who appreciate this rather
essential fact, here is a quote from a part of the GNU CC manuals, and
more precisely, amusingly, from the manual for the GNU Objective C
runtime system manual:
http://GCC.GNU.org/onlinedocs/objc-features.html
"GNU Objective-C runtime features
This document is meant to describe some of the GNU Objective-C
runtime features. It is not intended to teach you Objective-C, there
are several resources on the Internet that present the language."
Also, in the [Cocoa] Objective-C documentation (that in some parts
however is quite objectionable) at:
http://developer.Apple.com/techpubs/macosx/Cocoa/ObjectiveC/
and its table of contents looks like:
"* Object-Oriented Programming
* The Objective-C Language
* Objective-C Extensions
* The Run-Time System
* Object Ownership and Automatic Disposal
* Objective-C Language Summary
* Reference Manual for the Objective-C Language
* Glossary"
and correctly the language, its Cocoa-specific extensions, and the run
time systems are presented as wholly different subjects; the section on
the runtime system even says:
[ ... ] "The run-time system has a public interface, consisting mainly
of a set of functions. Many are functions that duplicate what you get
automatically by writing Objective-C code or what the NSObject class
provides with a method interface. Others manipulate low-level run-time
processes and data structures. These functions make it possible to
develop other interfaces to the run-time system and produce tools that
augment the development environment; they're not needed when
programming in Objective-C." [ ... ]
Ignorant buffoons that write "Objective-C is largely defined by its
runtime" and argue on the basis of this imbecility evidently have never
bothered to read even this simple introduction to one of the more popular
modern variants of the language.
[ ... ]
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
Brad Cox> "the textual, synchronous objects of Objective-C; objects that
Brad Cox> communicate by sending each other messages where the receiver
Brad Cox> computes as a subroutine of the sender, rather than as a coroutine."
======================================
jcr> This quote in no way supports your contention that Obj-C
jcr> doesn't perform message-passing.
Really? What it explicitly says is that Objective-C model of computation
is actually that of calling subroutines.
Brad Cox> "But as you point out, such objects are still *passive*, in that
Brad Cox> they lie there as limply as conventional data variables until the
Brad Cox> outside world passes them a thread of control, which they share as
=============
Brad Cox> subroutines, rather than as coroutines."
===========
jcr> Again, this quote also fails to support your position. So Cox says
jcr> that objects have to wait for a thread of control. So what? [
jcr> ... ]
The very clear word he uses when describing the semantics of ``message
passing'' is "subroutine", again, and objects are simply "data
variables".
The semantics are described as those subroutines (nested control
transfers), not even those of coroutines (continuations), never mind
those of asynchronous message passing.
Given the context it is also clear that he somewhat regrets that the
actual semantics of Objective-C are those of calling subroutines, and
not those of [asynchronous] message passing, as he thinks that these are
more appropriate for high-level application building for non programmers.
Piercarlo Grandi
>>> said:
Brad Cox> Stepstone's experience with Objective-C is a final example of
Brad Cox> why a multilevel software architecture is desirable. Whereas
Brad Cox> Metaphor's experience shows that skilled programmers need
Brad Cox> lower-level architectural standards than Metaphor's card-level
Brad Cox> objects, Stepstone's experience shows that users need
Brad Cox> higher-level kinds of objects than the textual, synchronous
Brad Cox> objects of Objective-C; objects that communicate by sending
Brad Cox> each other messages where the receiver computes as a
Brad Cox> subroutine of the sender, rather than as a coroutine.
marcel> [ ... ] The above quote seems to quite clearly distinguish two
marcel> different kinds of message passing.
Only imbeciles "clearly" understand "message passing" when "computes as
a subroutine" is actually what is written as being the semantics of
``messaging'' for the "synchronous objects of Objective-C".
The passage is actually about the desirability of "higher-level kinds of
objects" rather than the "textual, synchronous objects of Objective-C",
where the "receiver computes as a subroutine of the sender".
What Brad Cox is alluding to here and in the rest of his papers and
works is what are now known as the distributed objects supported by
frameworks such as CORBA or GNUStep; his concept of higher level,
asynchronous, truly message passing (and not subroutine calling) based
objects has been realized in many CORBA/DO applications, which are
pretty popular nowadays.
In fact, exactly as he wrote, such higher level objects are fruitfully
_implemented_ on top ("a multi level software architecture") of the
subroutine style semantics of languages like Objective-C or Java or C++,
which is all right and good, because message passing semantics are
pretty inconvenient and slow.
Instead shared memory, control transfer, applicative semantics are,
where they can be supported directly, much faster and easier to use,
which is the main reason why very very few languages, and surely not
Objective-C or any other popular language, are based on message
passing semantics.
Try to imagine what would happen if your hallucinations that Objective-C
is based on concurrent OO, message passing, semantics, were actually
true: one could not pass pointers as arguments, or one could not use
global variables, or any other source of side-effects; each object would
need to be written to synchronize explicitly with any other object it
communicates with by using patterns of message passing.
Note that it is not a matter of optimisation: of course the
implementation of message passing can be optimised if the messaging is
not actually distributed, but if the semantics of message passing must
be respected, then no object behaviour that depends on shared-memory,
synchronous subroutining semantics could be allowed.
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On 23 Apr 2001 21:48:24 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
> >>> said:
>
> [ ... ]
>
> marcel> Objective-C is largely defined by its runtime.
>
> This is a masterpiece of kookdom: it is a statement that at the same
> time demonstrates ignorance of what a language is, how Objective C is
> actually defined, lack of a computer science education, arrogance,
> buffoonery, disrespect for the audience, and utter dishonesty.
>
> The statement above is not in fact just stupid: it is a shameless,
> obvious, lie.
Grandi, now you've gone beyond the amusing to the irritating. Marcel is
major contributor not only to the Obj-C community, but the
Smalltalk/Squeak community as well. He has been very patient with your
posturing and your obnoxious insistence that anyone who disagrees with
you is ignorant of computer science.
You have been shown that
1) Obj-C passes messages (even by your own ridiculously narrow
definition of message-passing)
and
2) Obj-C has metaclasses (Even though you're incapable of compiling
Marcel's proof thereof.)
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On 23 Apr 2001 21:57:58 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
> >>> said:
>
> Brad Cox> Stepstone's experience with Objective-C is a final example of
> Brad Cox> why a multilevel software architecture is desirable. Whereas
> Brad Cox> Metaphor's experience shows that skilled programmers need
> Brad Cox> lower-level architectural standards than Metaphor's card-level
> Brad Cox> objects, Stepstone's experience shows that users need
> Brad Cox> higher-level kinds of objects than the textual, synchronous
> Brad Cox> objects of Objective-C; objects that communicate by sending
> Brad Cox> each other messages where the receiver computes as a
> Brad Cox> subroutine of the sender, rather than as a coroutine.
>
> marcel> [ ... ] The above quote seems to quite clearly distinguish two
> marcel> different kinds of message passing.
>
> Only imbeciles "clearly" understand "message passing" when "computes as
> a subroutine" is actually what is written as being the semantics of
> ``messaging'' for the "synchronous objects of Objective-C".
Grandi, read it again. Cox describes two different kinds of message
passing. You're the only one who insists that one mode is messaging and
the other is not.
By your twisted logic, I could claim that actor-based languages don't do
any messaging either, because when you get down to the metal, it's all
done in microcode that has no concept of a message.
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Mon, 23 Apr 2001 14:56:30 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
>
> [ ... ]
>
> pg> You are confusing (with quite a bit of imagination) the layout of
> pg> internal runtime datastructures (which includes the 'isa' pointer) with
> pg> a class object or a metaclass, which are _language_ level entities (and
> pg> the 'isa' pointer is not).
>
> jcr> Marcel is not "confusing" the runtime data structures, he is
> jcr> using them to show you what objects belong to what class.
> jcr> Obj-C binds objects to their classes through the isa pointer.
>
> But there is not such thing as the 'isa' pointer in Objective C: try to
> find anywhere in the Cocoa Objective C reference manual, for example,
> any mention of the 'isa' pointer.
Try to find any implementation of Obj-C which *doesn't* have an "isa" pointer.
>There is an 'isa' variable in the
> implementation of class 'Object', but given that it is invisible to
> programs it is not part of the language.
Your "given" is incorrect. In any implementation of Obj-C, the isa
pointer is entirely visible to programs. Code can access the isa
pointer with self->isa, *self, or [self class]. Take your pick.
[the rest of grandi's irrelevancies snipped]
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Mon, 23 Apr 2001 14:40:02 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
>
> [ ... ]
>
> Brad Cox> "the textual, synchronous objects of Objective-C; objects that
> Brad Cox> communicate by sending each other messages where the receiver
> Brad Cox> computes as a subroutine of the sender, rather than as a coroutine."
> ======================================
>
> jcr> This quote in no way supports your contention that Obj-C
> jcr> doesn't perform message-passing.
>
> Really? What it explicitly says is that Objective-C model of computation
> is actually that of calling subroutines.
And it is your *sole* contention, shared by no-one else, that "calling
subroutines" is somehow mutually exclusive with "passing messages."
Obj-C passes messages BY calling objc_msgSend() to look up the code to
act upon the message, and then jump to that code. So what?
> Brad Cox> "But as you point out, such objects are still *passive*, in that
> Brad Cox> they lie there as limply as conventional data variables until the
> Brad Cox> outside world passes them a thread of control, which they share as
> =============
> Brad Cox> subroutines, rather than as coroutines."
> ===========
>
> jcr> Again, this quote also fails to support your position. So Cox says
> jcr> that objects have to wait for a thread of control. So what? [
> jcr> ... ]
>
> The very clear word he uses when describing the semantics of ``message
> passing'' is "subroutine", again, and objects are simply "data
> variables".
I've got news for you: ALL objects are simply "data variables", whether
implmented in Obj-C, Smalltalk, or actor-based languages.
> The semantics are described as those subroutines (nested control
> transfers), not even those of coroutines (continuations), never mind
> those of asynchronous message passing.
You've been shown examples of asynchronous message passing in Obj-C.
Your hand-waving dismissals of those examples doesn't invalidate them.
-jcr
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
marcel> Objective-C is largely defined by its runtime.
>> This is a masterpiece of kookdom: it is a statement that at the same
>> time demonstrates ignorance of what a language is, how Objective C is
>> actually defined, lack of a computer science education, arrogance,
>> buffoonery, disrespect for the audience, and utter dishonesty.
>> The statement above is not in fact just stupid: it is a shameless,
>> obvious, lie.
[ ... ]
jcr> Grandi, now you've gone beyond the amusing to the irritating.
jcr> Marcel is major contributor not only to the Obj-C community, but
jcr> the Smalltalk/Squeak community as well.
How can anyone contribute anything of value when being a buffoon that
arrogantly and shrilly, confuses the properties of a runtime system and
those of the language, despite the clear, direct wording of the language
documentation and of the runtime reference documentation that states
they are distinct concepts?
I imagine someone like that could be something like an idiot-savant,
capable of writing useful if poorly designed code, but language and
implementation design require a minimum of familiarity with elementary
compsci notions like that.
Or at the very least they require the ability to comprehend the very
simple code examples that I have provided that prove that in GNU
Objective C method invocations actually use function call semantics thru
and thru (even for methods declared 'oneway'), and that in GNU Objective
C there is no such thing as a class object that is an instance of a
metaclass (the ``class'' attribute of a class descriptor structure
denotes the runtime structure for the class itself, not that for an
imaginary metaclass).
Instead, the code that he has provided shows only that it contains
invalid Objective C constructs, if only because of the
undefined-semantics casts that he has used; he can however hallucinate
some type punning and mistake it for a property of the language.
Piercarlo Grandi
[ ... ]
marcel> Message lookup proceeds identically, and there is no other
marcel> definition of 'object' in the language other than 'something
marcel> that responds to messages as sent via the runtime.
This is another example of deeply ignorant hallucination: in Objective C
objects are defined quite precisely as class instances, and a class
instance is some that is instantiated from a class, which is something
that is defined via an '@interface' and an '@implementation'.
Classes cannot be defined as C 'struct's, as you ignorantly assume
elsewhere; objects or classes and 'struct's are different concepts
with different properties, and are not interchangeable, even if the
runtime _representation_ of an object or a class is a 'struct'. The
distinction between an entity and its representation is one of the
cardinal concepts of OO, and you seem to gleefully unaware of it.
Your definition above is perhaps appropriate for Self or some similar
prototype language, whose semantics do involve per-object methods; it is
totally inappropriate for class based Objective-C; "In Objective-C, you
define objects by defining their class", as the Apple docs state (one of
the few correct things they say).
marcel> [ ... ] as sent via the runtime.
Morever in Objective C messages are not "sent via the runtime"; methods
are invoked using the Objective C primitive operator '[]', and the
runtime is just an implementation detail, which need not be involved in
the implementation of '[]': if the the class of the ``receiver'' is
known statically, selector resolution can be done at compiletime, and
the method can be invoked directly, and no runtime involvement is
needed prior to the subroutine call of the method.
This is a pretty basic notion about Objective C, yet by now I am not
surprised that you hallucinate otherwise.
[ ... ]
Piercarlo Grandi
>>> said:
[ ... ]
pg> as I have stated, and you have conveniently omitted, GNU Objective C
pg> supports the _syntax_ of the 'oneway' type qualifier, but does not
pg> support its _semantics_, as I have clearly proved.
[ ... ]
marcel> So you are drawing conclusions from one accidental implementation?
marcel> Tsk,Tsk, Tsk, shame on yo.
Despite your misrepresentation that I was generalizing the conclusion,
the discussion here was _strictly_ about the "GNU Objective C" (as I
clearly wrote) compiler, because I was discussing the peculiar fantasy
that:
Don> [ ... ] The NeXT/Apple/GNU (gcc) Objective-C compiler -- which is
Don> used by greater than 90% of the ObjC programmers out there --
Don> does allow definition of a "oneway void" method and the semantic
Don> is that the method should be considered asynchronous. [ ... ]
As I have easily proven, the "GNU (gcc) Objective-C compiler" does not
(yet) in any way provide asynchronous semantics for calling methods
tagged as 'oneway'; in fact it provides no language-level semantics for
it and the other DO qualifiers, actually in violation of their
definition: it can make a lot of semantic difference whether an 'inout
char *' argument is actually implemented with 'inout' semantics or not,
and GNU Objective C never does.
In the GNU scheme of things, it is GNUStep that does handle this
stuff, and only (???) for distributed objects. Other frameworks do
this too.
Beside, 'oneway' only turns the semantics of a nested control transfer
function call into those of non nested one (nice, but it is still not
message passing); the method invocation still has applicative semantics,
even if the implementation is allowed to turn the function call into the
spawning of a thread.
Applicative semantics extend to the creation of closures,
continuations, threads; unfortunately these are not part of Objective
C, but some other applicative languages, such as SL/5, Icon, Scheme,
etc. do have some or all of them.
But this was not my point yet, here it was narrowly that even if
'oneway' is an IDL style facility that has been overhastily embedded in
the language syntax, the GNU Objective C compiler does not implement its
semantics.
[ ... ]
John C. Randolph
Piercarlo Grandi, (describing himself, but apparently thinking that he's
describing Marcel) wrote:
> How can anyone contribute anything of value when being a buffoon that
> arrogantly and shrilly, confuses the properties of a runtime system and
> those of the language, despite the clear, direct wording of the language
> documentation and of the runtime reference documentation that states
> they are distinct concepts?
Marcel already told you: Obj-C is largely defined by its runtime.
You're the only one who maintains otherwise.
> I imagine someone like that could be something like an idiot-savant,
> capable of writing useful if poorly designed code, but language and
> implementation design require a minimum of familiarity with elementary
> compsci notions like that.
Well, since Marcel has implemented Obj-C itself, extended it with his
High-Order Messaging code, written a postscript interpreter in Obj-C),
and ported Squeak to a number of environments, I conclude that he knows
what he's doing.
You, on the other hand, have staked out this absurd position that
message passing isn't message passing unless it's done asynchronously,
and gotten more and more obnoxious at our refusal to agree with you.
-jcr
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
marcel> [ ... ] The above quote seems to quite clearly distinguish two
marcel> different kinds of message passing.
>> Only imbeciles "clearly" understand "message passing" when "computes as
>> a subroutine" is actually what is written as being the semantics of
>> ``messaging'' for the "synchronous objects of Objective-C".
jcr.remove> Grandi, read it again. Cox describes two different kinds of
jcr.remove> message passing. [ ... ]
Do you think Brad Cox is the sort person that says "compute a
subroutine" when he really means "message passing"?
It is bad enough that by ``send a message'' he means "computes as a
subroutine", and not "messate passing", but to claim that he means
"message passing" when he actually writes "computes as a subroutine"
seems to be fantasy running riot all over again.
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... [
pg> There is an 'isa' variable in the implementation of class 'Object',
pg> but given that it is invisible to programs it is not part of the
pg> language.
jcr> Your "given" is incorrect.
Not quite, but perhaps I should have been more explicit... See below.
jcr> In any implementation of Obj-C, the isa pointer [ ... continues
jcr> below ... ]
In any *implementation* out there that I know of there is an isa
internal variable; it is however a particular feature of the
*implementation* of 'Object', as I wrote, not of its public,
program-wide interface.
Also, the characteristics of 'Object', including its name ('NSObject'
anybody? :->) seem to be a bit to the taste of the implementer, I find
it difficult to claim that an internal 'Object' variable called 'isa' is
a part of the language; even the name of the root class seems not to be.
But then there are some buffoons that claim that even small details of
the runtime system implementation are part of the language
definition...
Also, some implementations provide '@private'; is there anything that
forbids the implementor of 'Object' to declare it as '@private'? If not
so, 'isa' cannot be reliably/portably used even in the implementation
of any class other than 'Object'.
Too bad that the current _language_ specs do not prescribe much about
the public properties of 'Object', never mind the internal ones; even
claiming that '[anObj class]' is a feature of the language seems risky
to me (even if it should not be), never mind 'isa'.
jcr> the isa pointer is entirely visible to programs.
Not entirely! as I wrote, it is only visible to the _implementation_ of
the classes to which it belongs ('Object' and, of course, its
descendants, unless it is '@private') in those programs; I don't know of
any Objective C dialect that makes 'isa' a '@public' attribute (and I
hope nobody does anything like that).
jcr> Code can access the isa pointer with self->isa, *self,
Again, the 'code' is only the "implementation" code, and this is an
essential qualifier, implicit in your use of 'self'; also, '*self' is
rather dodgy (euphemism) typewise:
------------------------------------------------------------------------
$ cat illegalType.m
#include <objc/Object.h>
@interface Tag: Object
{ const char *tag; }
- (void) tag: (const char *) t;
- (const char *) tag;
- (const Class) myIsA;
- (const Class) mySelfIsA;
- (const Class) myStarSelf;
@end
@implementation Tag
- (void) tag: (const char *) t { tag = t; }
- (const char *) tag { return tag; }
- (const Class) myIsA { return isa; }
- (const Class) mySelfIsA { return self->isa; }
- (const Class) myStarSelf { return *self; }
@end
bash-2.04$ gcc -c illegalType.m
illegalType.m: In function `-[Tag myStarSelf]':
illegalType.m:19: incompatible types in return
$
------------------------------------------------------------------------
I guess you belong to the same happy type punning crowd as Marcel :-),
you could have said '*(Class *) self'.
jcr> or [self class]. Take your pick.
This is OK, like '[anObj class]' it is a valid expression, in the entire
program and not just the implementation, and one hopes that all the
Objective C variants do have an 'Object' (or whatever) 'class' method.
But it is a rather grave mistake to present a method call that returns
the value of an instance variable as an example of the visibility of an
instance variable itself, they are _very_ different concepts.
Still, '[anObj class]' is OK, and that I have used that in an example
it's after all (hopefully) fairly ``standard''.
However the difficulty is that there is no reliable definition of the
properties of a 'Class' value (which is not an object: it is a pointer
to a 'struct', and C 'struct' values are not objects, or else C itself
would be OO), so one must still tease metadata out of it using
implementation dependent runtime C functions, which are not part of the
language, but of its runtime implementation.
John C. Randolph
Piercarlo Grandi wrote:
>
> But this was not my point yet, here it was narrowly that even if
> 'oneway' is an IDL style facility that has been overhastily embedded in
> the language syntax, the GNU Objective C compiler does not implement its
> semantics.
I don't see what you gain by splitting hairs over whether it's the
compiler or the runtime that implements a particular feature of the
language. The "oneway" keyword is part of the language, and the most
common implementation of the language (GNU Obj-C) supports it. QED.
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Mon, 23 Apr 2001 19:38:54 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
> [ ... [
>
> pg> There is an 'isa' variable in the implementation of class 'Object',
> pg> but given that it is invisible to programs it is not part of the
> pg> language.
>
> jcr> Your "given" is incorrect.
>
> Not quite, but perhaps I should have been more explicit... See below.
No, I don't think I'll bother, since you'll never admit that you don't
know what you're talking about.
You stated that it's "given" that the isa pointer is invisible to
programs, and I showed you three ways (there are others, but three ways
should suffice) that it is indeed visible to programs.
-jcr
John C. Randolph
Piercarlo Grandi wrote:
>
> >>> On Mon, 23 Apr 2001 19:33:25 -0700, "John C. Randolph"
> >>> <jcr.r...@this.phrase.idiom.com> said:
>
> marcel> [ ... ] The above quote seems to quite clearly distinguish two
> marcel> different kinds of message passing.
>
> >> Only imbeciles "clearly" understand "message passing" when "computes as
> >> a subroutine" is actually what is written as being the semantics of
> >> ``messaging'' for the "synchronous objects of Objective-C".
>
> jcr.remove> Grandi, read it again. Cox describes two different kinds of
> jcr.remove> message passing. [ ... ]
>
> Do you think Brad Cox is the sort person that says "compute a
> subroutine" when he really means "message passing"?
I think that Cox realizes that Obj-C message passing, does not have to
pass some kind of arbitrary test of object independence that satisfies
you, in order to be message passing.
-jcr
Steven D. Majewski
Ignoring his dismissive tone, I think Piercarlo is right about one thing:
| In fact Objective-C _never ever_ sends a message to an object -- objects
| are just data in Objective-C. Have you ever used the language? There is
| simply no way to define per-object behaviour or to send a message to an
| object in Objective-C.
I would break with him, though, and say that it IS appropriate to say
that objective-c *does* send messages to classes.
(I think everyone in this discussion knows enough about obj-c method
dispatching to understand why I make that distinction -- if not,
then I'll take it up another time. )
Much of the rest of the discussion is about: What is a message?
The term is used in several domains and there doesn't seem to be a
uniform accepted definition.
"Message passing" is a type of parallel processing architecture, usually
contrasted with shared memory models.
It's used, as Piercarlo pointed out, in Actors type systems & languages.
There is also a long history of usage in what's called object-oriented
programming languages -- specifically Smalltalk and Objective-C. Piercarlo
may decry that it's use there may not be logical and consistent with it's
use in other domains, but long usage usually trumps logic. ( There was a
recent article in Wash. Post magazine complaining about the fact that
dictionary editors believe it's there job to document usage, not to
proscribe it.) A good example in CS in the term Object-Oriented -- because
it was already 'taken', a stronger sounding term -- "Object Based" was
used in taxonomies to describe a somewhat weaker version of objectness.
Piercarlo would like to stick to a narrower definition. It's one thing to
complain that the common usage isn't logical -- it's another to accuse
those who conform to the common usage to be simple minded fools -- which
is what PG seems to do. )
What is a message? -- trying to abstract from those and Piercarlo's
examples, I come up with three features:
[1] It's symbolic leaving the receiver with autonomy on how to interpret it.
This is the sense in O-O, and is what makes objective-c method dispatch
distinctly different from C++.
It doesn't matter that the dispatch is done by a single bit of code
unconnected to the object -- the semantics are identical to the case
where a symbolic message is sent ( in any sense of the word you
want to use, over any channel ) to the class. ( Not Object! )
[2] Copying --
but copying is only significant when the processes are asynchronous.
(That's why it's a concern for the parallel arch. folks.)
(See: <http://theory.Stanford.edu/people/jcm/cs358-96/actors.html>)
In a synchronous system without parallelism, copying semantics is
identical to non-copying semantics.
And as others have pointed out: when obj-c does do parallel
processing with Distrib. Obj., it does do copying and can be
asynchronous.
[3] Control thread: parallel, asynchronous, non-determinate. But:
<http://IC-WWW.ARC.NASA.gov/ic/darwin/oif/leo/filman/text/dpl/hewitt.pdf>
describes an actor system which is implemented using continuations
and is serial, synchronous and determinate, so that doesn't
seem to be a requirement.
Looks like #1 is the most important quality.
If there is a platonic ideal of object-orientedness, the an actors
system is the fullest realization of that ideal.
I dug out my Brad Cox book, and some other early o-o writings, and
it does seem to be reasonable to read them as if they did have some
such platonic ideal in mind, and Smalltalk, Objective-C, C++, et.al.
where all exercises in the practical application of that model.
Rather than Piercarlo's binary distinction, which seems to lump
everything that's not an actor language as identical to C or assembler,
I would view it as successively better approximations to the O-O ideal:
static, class-oriented o-o [C++]
dynamic, class-oriented o-o [obj-C,Smalltalk]
delegation, class-oriented o-o [Python]
prototype O-O [Self, Newtonscript, xlispstat]
Actors
Another orthogonal issue is the degree of introspection, reflexivity,
Meta-Object-Programming supported.
To a large extent, the runtime IS the semantics.
( Like the way that FORTH is defined by it's virtual machine.
Lisp can be described that way, but it's also more explicable
as a more abstract formal system. This is especially true for
systems that haven't been standardized with a formal definition. )
How easy or natural it is to extend the protocols determines how
flexible are the semantics. ( CLOS might be a good example. )
-- Steve Majewski
Steven D. Majewski
Piercarlo Grandi <pg...@sabi.Clara.co.UK> wrote:
>>>> On 23 Apr 2001 21:48:24 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
>>>> said:
>
>[ ... ]
>
>marcel> Objective-C is largely defined by its runtime.
>
>This is a masterpiece of kookdom: it is a statement that at the same
>time demonstrates ignorance of what a language is, how Objective C is
>actually defined, lack of a computer science education, arrogance,
>buffoonery, disrespect for the audience, and utter dishonesty.
>
>The statement above is not in fact just stupid: it is a shameless,
>obvious, lie.
>
Piercarlo:
Denotational Semantics is not the only way to define semantics.
Virtual Machine definitions (which is more or less another way
of saying runtime) are also common. It's a common, although not
the only way, of defining Lisp. It's probably the only way to
define something like Forth. Languages which are not standardized
and lack a more formal definition, like Python, for an example
other than objective-C, are pretty much defined defacto by their
runtime.
I thought you actually made a couple of good points in this
discussion (see my other post). Why all of the insults and
ridicule ? Don't you think your arguments can stand on their own?
-- Steve Majewski
Piercarlo Grandi
>>> <jcr.r...@this.phrase.idiom.com> said:
[ ... ]
pg> What it explicitly says is that Objective-C model of computation is
pg> actually that of calling subroutines.
jcr> And it is your *sole* contention, shared by no-one else,
jcr> that "calling subroutines" is somehow mutually exclusive
jcr> with "passing messages."
Ahhh, not quite, and perhaps I haven't been clear as to this, it's not
"mutually exclusive": programs can do both function calling and message
passing, but only the former actually happens in Objective C, the
language, narrowly defined, and the latter happens in the DO schemes
built on top of it, which or more or less what is clumsily said in:
http://developer.Apple.com/techpubs/macosx/Cocoa/ObjectiveC/4MoreObjC/index.html
Rather than "mutually exclusive" I tried to say ``profoundly
different''.
There is something like a few decades of compsci literature about the
very different semantic and performance properties of function calling
and message passing as general computational paradigms. Also, with
discussions even shriller than this as to which one is ``best'' (message
passing seems to be winning hands down for massively parallel machines,
clusters in particular).
BTW, reconsidering those pretty shrill academic discussions I realize
that I was too shrill myself in my reaction to Marcel's position that
the definition of Objective-C is largely that of its runtime system
(IIRC); I still think it is scandalous, but I apologise for the tone
and the excessively unpleasant concepts I used. Sorry Marcel!
In my defense I'll say that I felt really duped: I had been trying to
illustrate my argument about the semantics of Objective C, and I could
have stretched it to discuss (even if I disagree) the merit of the
idea that some message passing DO framework that extends Objective C
_might_ be considered in practice part of what many people may
(mis)understand as Objective C nowadays; but a ``runtime semantics''
position is so utterly alien to such a discussion that to bring it up
after quite a while seemed a deliberate attempt to first wind me up
only to then say ``but we are not even in the same universe bye bye
bye, and I knew it all along nyah nyah nyah''.
[ ... ]
jcr> Obj-C passes messages BY calling objc_msgSend() to look up the code
jcr> to act upon the message, and then jump to that code. So what?
Well, we are at least in the same universe here, not necessarily on the
same continent of the same planet though, but getting closer...
It's sort of fine by me, even if it's a runtime-level view (and even the
of a specific runtimr; in the Objective C runtime I once wrote it's not
called 'objc_msgSend' :->), and I prefer a proper language-level view,
but it actually illustrates the semantics of the language (narrowly
defined) to those that look at things thru runtime-tinted spectacles,
and despite everything I have tried to accomodate that point of view.
If you want we can agree to a truce on the following basis:
Communication between computational entities is traditionally called
"messaging"; this actually results in dynamic dispatching between
methods in Objective C and in message passing between objects in the
DO frameworks that extend Objective C (a "multilevel architecture").
It feels a bit strange to me to say that "messaging" is not necessarily
related to "message passing", but if you want to call "obj selector:
arg" a message even when it is actually a dynamically dispatched method
invocation, fine.
jcr> I've got news for you: ALL objects are simply "data variables",
jcr> whether implmented in Obj-C, Smalltalk, or actor-based languages.
Uhhhh, in the case of actor-based languages, it's not "simply".
That's precisely part of the huge semantic difference between
applicative and actor style message passing OO: actors _are_ active, and
consist of both some state (a set of acquaintances) *and* a thread
executing a script that drives their behaviour.
Not simply of state/data; also, there is really message passing between
objects, because there is no way for the script in one actor to interact
directly with the script in another, only via messages.
A particular computation in a traditional language is some sequences of
(dynamically dispatched) method invocations, synchronous or not, in an
actor one it is a pattern of messages being passed from actor to actor.
Note also that in actor languages the message is not a passive list of
arguments that is bound to a list of parameter local variables
(environment instantiation); a message is an actor itself, and the
receiving actor's script ``parses'' it by sending it messages, so not
only there is no control transfer, nested or not, synchronous or not,
there is no environment instantiation either.
Put another way, and very tersely, a traditional object is a (passive)
closure with function attributes, but an actor is an (active) process
with a single running script; both are opaque (the closure to
functions not bound within it, the process to all the other scripts
that are not run by it), in the OO sense.
Actor objects are semantically very different from those (later
versions) of ``Smalltalk'' or Objective-C, or C++ or Java, they are not
"simply "data variables"" and it is a hugely interesting approach in its
own right.
BTW, just as there is an actor version of C++, Act++, one could design
an actor version of Objective C; it could be pretty interesting, and
surely Objective C and one of its frameworks would be a much better
starting point than C++.
As far as I can see in the work of Brad Cox, he sees software ICs as
passive, traditional objects, that are assembled in virtual cards in
some virtual backplane, and the cards are active in the actor sense.
Imagine software ICs as being the software bits loaded on the ROM of a
router, and the cardware being the running router (the virtual
backplane being the network), each router an actor that is part of a
message passing society of routers.
There is a book out there, "Out of control", which predicts quite
reasonably that networks of all sorts in our future will be societies of
autonomous, high level computational actors whose scripts are
collections of of software ICs and that spend most of their time
messaging each other instead of doing ``useful'' stuff -- a bit like
USENET :-).
Marcel Weiher
>>>> On 23 Apr 2001 21:48:24 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
>>>> said:
>[ ... ]
>marcel> Objective-C is largely defined by its runtime.
>This is a masterpiece of kookdom: it is a statement that at the same
>time demonstrates ignorance of what a language is, how Objective C is
>actually defined, lack of a computer science education, arrogance,
>buffoonery, disrespect for the audience, and utter dishonesty.
Since there is no formal language specification, what Objective-C
is *is* defined by its implementation, and that, to a very large
extent, is its runtime. So I gladly send all those nice compliments
back to the person who deserves them: you.
>It is a fact that Objective C, the original base language, was rather
>well defined not by a runtime system but by a book,
By the runtime system described in the book. Which, incidentally
also describes the meta-class system (he calls them 'shared parts').
Page 75
"The same rules that apply to instances apply to factory
objects too. Figure 5.6 shows the various parts of the
factory object for class Symbol. It is constructed
exactly like the symbol instance. It has its own
private and shared parts, and messages and inheritance
work exactly the same as they do for instances."
from exactly this book:
>* Brad Cox, "Object-Oriented Programming: An Evolutionary Approach",
>* Addison-Wesley, 1986.
Anyway, twit, if you actually knew something about the language,
you would know this, but you don't, but what can one expect of
an ignorant twit like you...
Marcel Weiher
>>>> On Mon, 23 Apr 2001 14:40:02 -0700, "John C. Randolph"
>>>> <jcr.r...@this.phrase.idiom.com> said:
>[ ... ]
>Brad Cox> "the textual, synchronous objects of Objective-C; objects that
>Brad Cox> communicate by sending each other messages where the receiver
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Brad Cox> computes as a subroutine of the sender, rather than as a coroutine."
> ======================================
>jcr> This quote in no way supports your contention that Obj-C
>jcr> doesn't perform message-passing.
>Really? What it explicitly says is that Objective-C model of computation
>is actually that of calling subroutines.
The quote also quite clearly states that this is considered sending
messages. Learn to read.
Marcel Weiher
>>>> On 23 Apr 2001 21:57:58 GMT, mar...@cs.tu-berlin.de (Marcel Weiher)
>>>> said:
>Brad Cox> Stepstone's experience with Objective-C is a final example of
>Brad Cox> why a multilevel software architecture is desirable. Whereas
>Brad Cox> Metaphor's experience shows that skilled programmers need
>Brad Cox> lower-level architectural standards than Metaphor's card-level
>Brad Cox> objects, Stepstone's experience shows that users need
>Brad Cox> higher-level kinds of objects than the textual, synchronous
>Brad Cox> objects of Objective-C; objects that communicate by sending
^^^^^^^^^^^^^^^^^^^^^^
>Brad Cox> each other messages where the receiver computes as a
^^^^^^^^^^^^^^^^^^^
>Brad Cox> subroutine of the sender, rather than as a coroutine.
>marcel> [ ... ] The above quote seems to quite clearly distinguish two
>marcel> different kinds of message passing.
>Only imbeciles "clearly" understand "message passing" when "computes as
>a subroutine" is actually what is written as being the semantics of
>``messaging'' for the "synchronous objects of Objective-C".
Learn to read. It would help you look less like a fool, though I
doubt much can help you in that department.
Marcel Weiher
>But there is not such thing as the 'isa' pointer in Objective C: try to
>find anywhere in the Cocoa Objective C reference manual, for example,
>any mention of the 'isa' pointer.
So anything that's not in the Cocoa reference manuals doesn't exist?
You really crack me up. According to this 'defintion' there are
no instance variables in Objective-C, because all Cocoa refs.
only document the message interface to objects. Duh.
Marcel Weiher
>and that in GNU Objective
>C there is no such thing as a class object that is an instance of a
>metaclass (the ``class'' attribute of a class descriptor structure
>denotes the runtime structure for the class itself, not that for an
>imaginary metaclass).
This is not true and easily checkable. Of course, the -class
method as defined by classes returns the class itself, but
you wouldn't know that this just a feature of that method,
not an accurate reflection of the actual runtime structures.
Marcel Weiher
>>>> On 23 Apr 2001 21:48:24 GMT, mar...@cs.tu-berlin.de (Marcel Weiher) said:
>[ ... ]
>marcel> Message lookup proceeds identically, and there is no other
>marcel> definition of 'object' in the language other than 'something
>marcel> that responds to messages as sent via the runtime.
>This is another example of deeply ignorant hallucination: in Objective C
>objects are defined quite precisely as class instances, and a class
>instance is some that is instantiated from a class, which is something
>that is defined via an '@interface' and an '@implementation'.
These constructs are nothing but syntactic sugar for constructing
the necessary structures as used by the runtime.
From the Cox boook, page 55-56:
"Messages are sent by writing message expressions, which are
translated directly into calls on the messager. In fact,
were it not for needing a bit of compile-time assistane,
in defining new classes, the special syntax might well be
dispensed with altogether and calls be written directly
on the messaging routine, like this: [..]
This would not require any special syntax, and no new tools
to handle the modified syntax. And it models the intended
semantics perfectly. In fact, the only reson for not adopting
this path is efficiency. A compile-time tool is needed to
convert message selectors into some representation that can
be compared efficiently to avoid string comparison overhead
in the messager."
So, the intended semantics are defined by the runtime functions, the
language syntax that you are so hung up on is only there at all
because of a need to optimize message sending (though it *does*
give a somewhat nice syntax as well...)
Of course, someone who actually knew this language well enough
to be pontificating on it would have known that...
> Classes cannot be defined as C 'struct's, as you ignorantly assume
> elsewhere;
Of *course* they can. They are nothing *but* C structs. Once again,
Objective-C is a superset of C, and C is used to define all its
constructs.
> objects or classes and 'struct's are different concepts
Oh my, you really don't know anything about Objective-C, do you?
> with different properties, and are not interchangeable, even if the
> runtime _representation_ of an object or a class is a 'struct'.
What you are forgetting is that this runtime representation is
accessible to the language itself due to the fact that the C code
that is used for all this definition work is *part* of Objective-C.
>Your definition above is perhaps appropriate for Self or some similar
>prototype language, whose semantics do involve per-object methods;
All of this has nothing to do with per-object methods, it has to do
with classes being represented as kinds of objects, although in
Objective-C, these objects are pretty much fixed.
>Morever in Objective C messages are not "sent via the runtime"; methods
>are invoked using the Objective C primitive operator '[]',
See the above quote from Cox as to how much bollocks that is.
Messages are sent via the runtime. The '[]' syntax is syntactic
sugure (and nice one at that) that is nice but unecessary.
>and the
>runtime is just an implementation detail,
You clearly don't know Objective-C very well. The object model is
the central feature of Objective-C, the syntax is the implementation
detail, though a nice one.
[more silly posturing snipped]