RFC: Allocating via a protocol/interface
RFC: Allocating via a protocol/interface
- Subject: RFC: Allocating via a protocol/interface
- From: Michael Gersten <email@hidden>
- Date: Sun, 30 Jun 2002 22:48:00 -0700
This is a request for comments.
The goal is to be able to allocate a class that isn't known at compile time, based on the output of a function. In ObjC,
myObject = [[ someFunc( ... ) alloc] init]
and in a way that Java can do this also.
The someFunc will take a protocol name, or interface name, and some additional flags (either as a varargs type of list, or an ordered collection) that specify properties. It returns a class.
So far, I've come up with the following:
1. A function that can examine the runtime, and find all of the classes that implement a protocol. Very doable in ObjC; Java unknown.
2. A way to query those classes that implement a certain protocol, and find out what properties it has. This is a simple query protocol/interface. (Is it really simple?)
Now, the next step is extendibility.
You want to be able to load new classes that weren't known when the program was written.
You don't load classes in ObjC/Cocoa, you load bundles.
A bundle can contain categories; some categories in one bundle might conflict with categories in another, or there might be ordering problems. The generic idea of "Just load every bundle in a common directory" isn't acceptable.
The best idea I've come up with (remember, this is a REQUEST for COMMENTS) is to have two bundles per loadable extension bundle. The first would always be loaded, and simply provide information about what's in the major bundle -- what protocols/categories are in the main, loading prerequisites, etc. This would just be a single class, with no real opportunity for conflicts.
Now, we don't want to limit this to just loading bundles from the file system. Java has shown us that being able to load from other places is a good thing. People have mentioned the idea of charging for the use of packages/frameworks; maybe the idea of a central registry that can track what a person has said they are willing to spend, and supplies an appropriately priced package with the wanted protocol/properties makes sense.
The best way to support all this that I can come up with is to say that each of these description classes is responsible for loading the full bundle; a (standard) parent of the description classes can know how to load from a filename (relative to the description class, or absolute), an NSFileHandle, or something similar, with a suitable default implementation in the parent that most description classes would need nothing to load the full thing. (Easiest implementation would be to make the description bundle contain a detail bundle).
So, what's left?
First, can anyone come up with flaws or drawbacks to this idea.
Second, can anyone help me come up with a good API that works for both ObjC and Java?
--
I am a Mac OS 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.