[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Case for a new runtime (Was: Re: Obj C and standards)
Case for a new runtime (Was: Re: Obj C and standards)
Fri, 13 Apr 2001 20:26:33 -0700
>If you have GC, you tend to forget about memory management ... and that's a
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
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
* A compiler
AFAIK the main changes will be with the ObjC library, not the compiler. gcc
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
* 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?
- Case for a new runtime (Was: Re: Obj C and standards),
strobe anarkhos <=