Re: State of Swarm on Mac OS X

[moetteli]

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.