Case for a new runtime (Was: Re: Obj C and standards)

[strobe anarkhos]

>
>If you have GC, you tend to forget about memory management ... and that's a 
>mistake.


In Java you can override it's garbage collector.

I mean why not lock data so it's disposed when released? We can do this in a 
general way and have interfaces to the functionality with extra NSObject 
methods. Don't use the methods and it acts like before.

It becomes a larger boon when you have a runtime which is general enough to be 
used with other languages. Thus all objects are general (I'll limit objects to 
smalltalk/Java/ObjC/TOM in this context) and any supported language can in it's 
own limited way create such objects and pass messages to them. All languages do 
not have to support all base methods, merely a syntax to pass a message to a 
method by name.

Take TOM and ObjC. TOM supports multiple inheritance, direct variable access, 
and variable class extensions (like categories but can add variables to 
existing classes thus no narrowing base class problem). TOM is essentially a 
superset of ObjC. However ObjC doesn't need to support multiple inheritance, 
direct variable access, variable class extensions, etc. to use the TOM runtime 
and use general objects. ObjC would merely have the limitations of:

* Not being able to create a new class from two others

* Not being able to access a variable directly (instead it would use standard 
methods like NSObject set: and get:)

* Not being able to add variables to existing classes.

This doesn't mean ObjC can't use objects TOM has created which use MI, or 
access variables created by class extensions. The objects are general, a ObjC 
object would be identical to a TOM object, they merely have a different runtime 
API to register and pass messages to objects.

Another example is Java and ObjC. I'm not going to get into the bytecode issues 
here so I'll just be talking about the language. Java supports GC, threading, 
and strict typing. Java does not support class extensions or forward invocation 
(security model + Sun stupidity). A general runtime would support a superset of 
these features. This does partially cripple Java's ability to use ObjC objects 
which are designed for forward invocation or loose typing, but we have that 
limitation anyway. ObjC can't use the runtime's threads, but Java could use 
ObjC objects with threading or GC. This would all be possible because all 
objects would be general, the only difference is the API used to register, pass 
messages to, control their execution (via per-object semaphore or whatever), 
and control their deletion (related to semaphores I'm sure).

Tieing this together is:

* A language neutral header format analogous to IDL.

This header could be generated automatically given the runtime status, 
providing the interface for a given object. Then it can be converted to a 
language-specific header.

Doing it this way allows non-objective languages like C to access methods in 
the current runtime which is an added benefit. This is a different approach 
than CoreFoundation (but can break more easily than CF).

* A general object runtime w/language specific libs using new protocol.

This runtime manages the general objects and must do so supporting a superset 
of features with respect to class extensions, base object methods, method 
execution control, object removal control (related to execution).

>From what I've seen looking at these various languages the only difference to 
>the ObjC language to support general objects is adding a few methods to it's 
>base class NSObject (which nobody has to use, it's entirely optional!). ObjC 
>would have to explicitly release an object so GC isn't an issue (a small 
>change to AutoReleasePool can use the general runtime's semaphore technique 
>instead of deallocating manually, but this is optional too). Methods would 
>likely be GOset: GOget: GOretain: GOrelease: (GO for general object, or 
>whatever). These methods would only need to be used if accessing 
>non-Objective-C objects, and only rarely. For example TOM can access variables 
>directly and may not have an appropriate method to set or get a value, but 
>this should be rare.

The bottom line is Foundation and AppKit would function exactly as they do now 
if no changes were made to the classes. In fact it may be possible to be binary 
compatible (but don't hold me to that).

The runtime would have it's own API which is used by the Objective-C library 
etc. Thus the Objective-C library has the same API, but when registering 
objects with the general runtime would likely use a slightly different 
protocol. Source (and perhaps binary) compatibility is thus maintained.

Finally the runtime should be able to take a snapshot of the current object 
hierarchy and construct an IDL-ish interface header which additional scripts 
can convert to a language-specific source file. In fact I don't see why IDL 
itself can't be used, or a subset of IDL. An IDL-to-doc script could also be 
made.

* A compiler

AFAIK the main changes will be with the ObjC library, not the compiler. gcc 
should work.

Summary:

A general runtime would be a lot of work, but you have many benefits:

* The ability to access an API written in any of the supported languages with 
the language of your choice.

* The ability to share your compiled code with others not using your language.

* You wouldn't need to know the syntax of other languages or the IDL syntax.

* You could browse the object hierarchy and create interfaces for the object 
you wish and start coding.

* Faster than any CORBA implementation, yet CORBA compatibility not out of the 
question.

* ObjC will gain features for those who want them. ObjC5 could be developed 
gaining features TOM currently has like no narrow base class problem.

* The last stand against non-objective solutions like C#, COM, CORBA and the 
growing army of C++ imitators. If you work within these runtimes/ORBs you lose 
features we take for granted in ObjC. However wrappers can be written for all 
of these interfaces so we have access to APIs written in them. Instead of us 
being assimilated by market forces, we assimilate them by wrapping functions.

A lot of work for a lot of gain, but what's going to happen if something like 
this doesn't materialize?

If people are interested in a project like this something could be setup at 
sourceforge. Having TOM and Objective-C use the same runtime would be IMHO a 
good 1.0 project as a proof of concept and to get a grip on logistical issues. 
Compiled Java (i.e. not a VM) using the Java gcc front-end may be a good 2.0, 
or perhaps smalltalk support (both have method execution control issues). 
Eventually VM support could become a reality (kinda waiting until a reasonably 
fast, open source one is available first).

We could call the project "GRO" for general runtime for objects.

I think the framework I've laid out is feasible. Am I the only one who thinks 
this is a great (yet unoriginal) idea?