[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of Swarm on Mac OS X
From: |
moetteli |
Subject: |
Re: State of Swarm on Mac OS X |
Date: |
Tue, 24 Sep 2002 00:31:47 +0200 |
Am Montag, 23.09.02, um 07:05 Uhr (Europe/Zurich) schrieb
address@hidden:
No, 'object_message_send_a_la_GNU()' is the official runtime function
for sending a message (I just don't have the official name handy). It
The GNU/Swarm Object.m is a wrapper for the classes in a C library -
libobjc. However, when I check the source of the incorporated
sendmsg.c,
I can see no sign of a function to make a Next/Apple style call.
I can't imagine that, but as I said, I don't have enough information
about the Gnu-ObjC yet, to know it.
OTOH
The Apple/Darwin Object.m is a wrapper for a collection of assembler
code
- hardly a C function to be seen anywhere. Once more the names of the
entry points give no hint of a routine to message a GNU object.
The '"hint" is in the header files of the ObjC runtime:
<objc/objc-*.h>. You can also check in the documentation. It's
mentioned many times.
Well I quickly looked it up for MOSX: It's declared in
<objc/objc-runtime.h> and it's called:
OBJC_EXPORT id objc_msgSend(id self, SEL op, ...);
And I'm sure, Gnu has the same thing, just with a slightly different
name and slightly different arguments. And it's the arguments, that
make your glueing proposition difficult.
Just have a look into Gnusteps implementation of '-performSelector:'.
While grovelling in the GCC web site, I found the following:
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01895.html
which refers to patches to speed up the GNU runtime. It also makes
comments about the different way that Apple does it. At this stage I
have
no idea whether those patches made it into the GNU runtime, never mind
Swarm.
Because Swarm doesn't patch the message dispatching system, but just
extends the object creation.
But my initial questions remain: Are people interested in replacing
the
foundation objects of Swarm with the Gnustep/Apple foundation objects?
I still don't see the benefit of that.
OO programming's basic idea is reusability. That means, don't learn,
design, implement, debug and maintain everything yourself. No, use
existing things. In our case, as I already said, this means many more
developers working indirectly for Swarm. And there are others: In those
Foundation libraries, there is a lot of very useful functionality, like
keyed encoding, distributed objects (something really insanely
great!!!), property list handling, etc, etc, etc. Everything constantly
evolving, without any time investment of any Swarm programmer at
anytime. Next advantage: There are many frameworks on MOSX/Gnustep and
the number is constantly growing. But you can't use them, if you don't
use the same Foundation libraries and your objects are not inheriting
from the same root object (NSObject). So if you want to use Swarm with
e. g. a Rule Base framework, like BDControl, offered for MOSX/Gnustep,
you simply just can't, because your different. So not only you can't
profit from the main reason, why OO exists – reusability – but you also
invest your own time, maintaining your own Foundations. You basically
pay at least double. So to resume: It is in any sense much cheaper.
And are they interested in cleaning up the code, the way, that direct
calls to the runtime are focused in just one location?
In principle, that sounds great, but only if it does not involve too
great
a speed penalty. OO purity is a great objective and would, as you say,
make the libraries much more portable, but the users have to be able
run
code at an acceptable speed.
I think it's a very low speed penalty. Especially with the Gnu ObjC
runtime, because it has the better selector lookup mechanism.
It seems to me to be a case of 'Fast, cheap, good - pick any two'.
Apple
have the resources to do fast and good. Swarm is probably stuck with
fast and cheap.
That's exactly the trap, non or pseudo OOSE (OO software engineers)
fall into: They think, "I quickly produce some code". That way, they
can quickly show something and that makes everybuddy happy. This is
possible for a small and tiny program, but not for something bigger
like, e. g. Swarm. The bigger the program, the more important design
becomes. So, when calling an OO program good, you basically say, that
it's design is good. Design should be 50% of the OO software lifecycly.
Now, the "surprising" conclusion is, that having a good design means
being cheaper already in the midterm.To say it shortly in your words:
Good and Cheap go together.
A problem is though, that only about 1 out of 1'000 OO programmers are
good designers. Most of them are not even aware.
Concerning fast is another question: If you don't have a good design,
you usually have more lines of code, you have to shuffle around a lot
more data structures, because you didn't encapsulate (fractionize) the
semantics of your program well. This means, your heap is often quite
big and as such there's a lot of work to swap it out. So I think again,
in a bigger program, the program is running faster with a good design.
Re
Phil
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.
Re: State of Swarm on Mac OS X, Ed Baskerville, 2002/09/24